What Does Your Custom PHP Site Actually Do? An Inventory Method

Custom PHP websites are often written once, extended many times and documented rarely. The original developer may be gone, and the business may rely on behavior nobody remembers was built. Before moving such a site, the most valuable exercise is to describe what it does from the outside in, and then confirm those findings in the code.

Start from behavior, not files

Reading every file from the top is slow and easy to get lost in. Begin instead with how people use the site:

• What can an anonymous visitor see and do?
• What can a logged-in user see and do, if logins exist?
• What do staff do in any admin area?
• What happens automatically without anyone clicking anything?

Write each answer as a short, testable statement, for example: a visitor can submit a quote request, and the office receives an email with the submitted details.

Map routes and entry points

List every public URL pattern. In older PHP sites, each file in the web root may be an entry point, and query parameters may switch behavior. In framework-based sites, a routes file usually lists them. Crawl the site, read server rewrite rules and check analytics landing pages to find routes that are not linked from navigation.

Find every form

Forms are where many sites do real work. For each form, record:

1. Where it appears.
2. Which fields it collects and which are required.
3. Validation rules and error messages.
4. Where submissions go: email, database, external API or several of these.
5. Any confirmation messages or follow-up emails.
6. Spam protection in use.

Look at the database

Export the schema and note each table's purpose, approximate row count and the code that reads or writes it. Some tables will be content, some will be operational records such as orders or submissions, and some will be abandoned. Personal data deserves careful handling and a retention decision before anything is copied.

Hunt for scheduled and background work

Check crontab entries, hosting control panel schedules and any scripts invoked by them. Background work often sends reminders, imports feeds, clears temporary files or generates reports. These jobs are the most commonly forgotten features in migrations because they have no page.

Note integrations and credentials

Search for outbound HTTP calls, SMTP settings, payment gateways, mapping services and API keys. Record which services the site talks to and who owns each account. Rotate credentials as part of the move rather than copying them into a new codebase.

Identify the PHP surface area

As part of the inventory, note which parts truly need server-side processing and which only render content that changes occasionally. Many marketing pages can be generated ahead of time or rendered by a modern framework, which reduces how much of the public site depends on a PHP runtime and the ongoing patching it requires. Features with real server logic, such as form handling or account areas, can be rebuilt as focused services with their own maintenance plan.

Turn findings into acceptance tests

Each behavior statement becomes a check in testing: perform the action on the new site and confirm the same outcome. This is the most reliable way to show nothing important was lost.

Why the effort pays off

A behavior inventory makes scoping honest. It shows which features are simple content, which are real application logic and which can be retired. It also leaves the business with documentation it probably never had, which is useful whatever platform comes next.