Taking over a PHP codebase
Access comes first, code second
The first job is finding everything. Domain registrar, DNS, hosting account, server logins, database, repository, email service, payment gateway, SMS provider, and any API keys baked into config files. We list them, confirm that you and not a former contractor own each account, and rotate the passwords and keys the previous developer knew. Then we take a full backup and restore it somewhere else. A backup that has never been restored is a hope, not a backup.
Getting the code under control
If there is no repository, we create one from what is running in production, since that is the only version that counts. If a repository exists, we compare it with the server, and it often differs because of hot fixes made directly on the live site. From then on nothing is edited on the server. We build a staging copy and a scripted deployment so a release is one command and can be reversed. Passwords and keys found in the code are moved into environment configuration.
What the audit looks at
We read the code the way a buyer inspects a house. Which PHP version does it need, and is that version still supported? Which Composer packages or bundled libraries have known vulnerabilities? Has anyone edited files inside the vendor folder by hand? Are errors printed to visitors or written to a log? Are queries parameterized? Can an uploaded file be executed? Where are the single points of failure, such as a cron job that emails invoices with no alert when it stops? The report sorts findings into fix now, fix soon and live with it. Not everything ugly is urgent, and we will not turn an audit into a sales pitch for a rewrite. If the PHP version is out of support, we scope that separately as a PHP migration and upgrade.
The monthly rhythm
Once stable, the work settles into a pattern. Security updates are applied to staging, checked and released. Logs and monitoring alerts are read and acted on, which is different from merely collecting them. Backlog items are picked up in priority order within the agreed hours, and you get a short report: what was updated, what was fixed, what we noticed, what we recommend next. Anything urgent, like a site down or a payment failure, jumps the queue.
Handover hygiene works both ways
We run every maintained application as if we might hand it over tomorrow. Documentation stays current, credentials live in a shared vault you control, and the repository sits in your organization. If you later hire in-house or move to another supplier, they receive a system in far better order than the one we inherited. That is the standard we wish every previous developer had kept.
