How do you safely take over an existing Laravel project?

1. Establish what actually runs in production

Collect the repository, deployed version identifier and environment descriptions. Check the PHP version, required extensions and Laravel version recorded in composer.lock. The web server, console commands and queue processes may use different PHP versions. This can explain errors occurring in only one place.

Compare composer.json with the lock file and installation instructions. First reproduce dependencies with composer install in an isolated environment. Composer update changes resolved versions, so it is not a neutral diagnostic step. Record how frontend assets are built and which tool versions are required.

2. Take over configuration without committing secrets

The .env.example file should describe required variables without containing real passwords. Transfer infrastructure and service access through a controlled channel, using individual accounts with revocable permissions. Check who can access production, domains, email, storage and backups.

Do not automatically generate a new APP_KEY in a running app: this may make data encrypted with the old key unreadable. A test environment should use its own integrations and data. If a production copy is needed, minimise and anonymise it; do not let it send messages to customers.

3. Check the database and migration history

Establish the database engine and version, data size and dependencies on extensions, views or procedures. Compare migration history with the actual schema. Do not assume the repository records every manual change made over the years.

Before a migration, check the backup and restoration procedure. Assess whether a change locks a large table, requires data backfilling or removes a column used by older code. Reverting an app release does not always revert a database schema change. The rollback plan must account for both.

4. Identify work performed outside HTTP requests

Map queues, drivers and worker processes. If Redis is used, identify its separate roles in caching, sessions and queues. A shared data-clearing command can have very different consequences depending on configuration.

Check recurring tasks, the scheduler and cron configuration, including time zones and protection against concurrent execution. Review queue timeouts, attempts and failed jobs. Retrying an operation must not accidentally submit a second order or charge an external system twice.

5. Map integrations and the deployment procedure

The integration inventory should include account ownership, test environments, limits and error detection. Check webhooks, signatures, retries and event ordering. Run tests with fakes or in a sandbox, not through accidental production service calls.

Trace the whole deployment: artifact building, configuration, migrations, caches, queue processes and post-deployment checks. Long-running processes need attention when code changes. Also establish who decides to roll back a release and under what conditions.

6. Observe the app before the first change

Review logs and current errors and exercise key user scenarios. Record a baseline: existing problems, key operation durations and queue backlogs. A working homepage alone does not prove the whole product works.

Run existing tests. If none exist, start with scenarios most easily broken: permissions, calculations, API contracts and integrations. A test describing current behaviour helps distinguish a regression from an intentional requirement change.

7. Plan updates in separate stages

List unsupported, vulnerable or development-blocking dependencies. For each update, check the upgrade guide for the installed version, PHP and package compatibility, and test scope. Avoid combining a major framework update with a business feature rewrite if that would make failures harder to diagnose.

The handover should produce a reproducible environment, an access and integration inventory, deployment and rollback instructions, critical-path tests and priorities for further work. Only then can later development stages be estimated responsibly.

This preparation is the starting point for Laravel app development and changes to the backend and API.

Documentation for your next steps

Use installation instructions that match the versions in your project. The sources below cover these topics in more detail.

• Laravel — deployment
• Laravel — queues