Taking over existing PHP software: how the assessment begins

The typical trigger

The triggers repeat themselves: the developer can no longer be reached. The application runs on a PHP version that no longer receives security updates, and the hosting provider announces its shutdown. A change is needed, but nobody dares to make it. Or the application works, but nobody knows how.

In all cases the first question is the same, and it is not "what does further development cost" but "what is actually there". Any statement about effort before this question is answered is a guess.

What is examined

An inventory assessment looks at five things:

• The technical foundation: PHP version, database, libraries in use and their maintenance status.
• The structure: is there a recognisable structure, or is the business logic scattered? This determines how expensive each change will be.
• The data storage: database structure, relationships, data quality — and whether the data is what the interface claims it is.
• Security-relevant areas: login, permission checks, handling of input, database queries, file uploads.
• Operations: where the application runs, how it is updated, whether backups exist, and whether a restore has ever been rehearsed.

The result is a written report with concrete findings — not a grade. "Outdated code" is not a statement; "the login checks permissions only after writing" is one.

What we need for it

• The source code, ideally with its version history. Access to an environment in which we can start the application — not necessarily the production environment. The structure of the database. For assessing the structure, an extract of the schema is usually enough. For assessing data quality we additionally need a sample or anonymised data that reflects reality. A contact person for the business questions: what is the application supposed to do? Often that is written down nowhere.

What we explicitly do not need is credentials for production systems sent by email. There are secure ways to provide access, and we only ask for what is necessary for the assessment.

Three possible outcomes

After the assessment, the answers usually come down to one of three directions: continue developing, renew step by step or rebuild. In some cases, replacing it with standard software or decommissioning it is the honest answer.

• Continue developing. The structure holds, the foundation can be updated, and changes are possible at manageable cost.
• Renew step by step. The application stays in operation, individual areas are replaced until hardly any legacy code remains. This is the most common route for applications that are needed in day-to-day business.
• Rebuild. When structure and data storage are such that every change brings more risk than benefit. This answer needs a justification with concrete findings; it is not a matter of taste.

What does not exist: a blanket "this has to be rebuilt". Anyone who says that without an assessment is selling a project, not a solution.

What a takeover fails on

• Missing access: without a runnable environment, every statement remains conjecture.
• No contact person for the business questions: code shows what happens, not why.
• No version history: then the answer to why something was built that way is missing.
• The expectation that the assessment costs nothing. It is the work that makes all later decisions sound.