Inherited a Laravel app? The first 10 days

Make a list of everything the application depends on, and find out who holds the keys.

• Repository, hosting, DNS, domain registrar, CDN and SSL.
• Payment provider, email service, SMS, storage buckets and any third-party APIs.
• Error tracking, uptime checks, analytics and the app store accounts, if there’s a mobile app.

Make sure these accounts belong to the business and not to a person. Then remove access for anyone who’s left, and rotate the secrets they could have seen: APP_KEY is a special case, so read on before you touch it. Database passwords and API keys can usually be rotated with little drama.

Changing APP_KEY affects anything encrypted with it, including encrypted database columns, and it signs out your users. Find out what uses it first. Laravel’s APP_PREVIOUS_KEYS setting supports a gradual rotation for many of those cases.

A backup isn’t proven until you’ve restored it. Restore the latest database and uploaded files to a separate environment and open the application against them. It’s common to find that files were never included, or that the backup job failed without anyone noticing. If you have no working backup, stop everything else until you do.

Read-only commands tell you a lot. Run them on a copy if you can.

php artisan about            # versions, drivers, cache state (Laravel 9.21+)
php artisan route:list        # the application's real surface
php artisan schedule:list     # what runs on its own
php artisan migrate:status    # has anything been left unapplied?
php artisan queue:failed      # work that has been quietly failing
composer audit                # known vulnerabilities in installed packages
composer outdated --direct    # how far behind your requirements are

Then look at what these don’t show: the server’s crontab, Supervisor config for queue workers, Nginx or Apache rules, and any shell scripts in the home directory. Applications often have a nightly job that exists only on the server. Compare the code on the server against the repository too, because a difference means someone has been editing in production, and those changes are lost at your next deploy.

Check your framework and PHP versions against Laravel’s support dates and the PHP matrix, and your packages against the compatibility matrix.

Code won’t tell you what matters most, so ask the people who use it. Sit with someone in each team and ask them to show you their week. Write down every flow they use, and mark those that make money, send something to a customer, or would cause harm if wrong. Ask what breaks often, what they’ve learned to work around, and what happens at month end.

This list becomes your manual test script and the priority order for automated tests. Write a few of those tests now, recording what the application does today. We used this kind of comparison on a cabinet manufacturer’s system, auditing the old code first and then checking workflows against it in parallel.

You need to be able to change one line and release it, without fear, before anything else goes wrong. If deployment today means someone uploading files, build the simplest repeatable process you can. Include how to go back. Then prove it by releasing something harmless, such as a comment or a footer change. Set up staging if there isn’t one, and make sure it can’t email real customers or charge real cards.

Add error tracking and uptime monitoring, if they’re missing. Check that logs rotate and that someone actually reads them. Look at failed jobs, slow queries and disk space. The goal this week isn’t to fix what you find. You just want to know the next time something goes wrong, before a customer tells you.

Put what you’ve found in one document, in plain language, for whoever pays for this application. For each item, say what could happen, how likely it is, and what fixing it would take. A typical order is:

1. Anything exploitable now: exposed secrets, known vulnerabilities, leftover debug settings or admin accounts.
2. Anything that could lose data: backups, single points of failure.
3. End-of-life software, with dates: framework, PHP, database and operating system.
4. Things that slow you down: missing tests, no staging, hand deployment.
5. Code quality. It’s tempting to put this first, and it usually belongs last.

Don’t rewrite anything because you dislike it. Code that looks wrong may have been shaped by a real requirement that nobody wrote down, so find out what it does before you decide.

You’ll now have an informed view of what to do. If the framework is out of support, plan the upgrade. Our guide to old Laravel versions helps you choose a route, and our checklist covers the process.

If you’d rather have help, our Laravel rescue service is built for this situation. Afterwards, Laravel maintenance is USD 99/month, invoiced in the customer's local currency, and developers start from $20/h if you need more hands.