Skip to content

Taking over existing PHP software and developing it further

An application has run for years, does its job — and nobody dares change anything in it any more. We survey what is there, tell you in writing and with references what is possible, and then develop the application further step by step while it stays in operation.

Visual metaphor: an existing bridge structure being renewed section by section.
Conceptual illustration of step-by-step modernisation.

Does one of these situations sound familiar?

  • The developer can no longer be reached, and nobody knows how the application is built.
  • The host announces the shutdown of a PHP version your application depends on.
  • A small functional change has been postponed for months because nobody can judge the consequences.
  • Reports produce figures that cannot be explained.
  • The application works — but there is no backup whose restore has ever been rehearsed.

In all of these cases the first question is not what further development costs, but what is actually there. Any statement about effort before that would be guesswork.

What we take on

  • A survey with a written finding: technical basis, structure, data storage, security-relevant points, operation.
  • Updating the basis to a PHP version that still receives security updates, including the libraries in use.
  • Replacing individual areas step by step while the application keeps running.
  • Technical takeover of support when the previous contact is no longer available.
  • Data clean-up where the finding shows that stored values contradict the interface.
  • Setting up backups and monitoring — and at least one rehearsed restore.

How a modernisation runs

The route is cut into stages, because an application in daily use cannot stand still for months. After every stage a state is reached at which one could stop.

  1. 1
    Survey what is there Technical basis, structure, data storage, security-relevant points and operation. The result is a written finding with references.
    MeanwhileThe application stays in operation unchanged.
  2. 2
    Update the basis Bringing the PHP version and the libraries to a state that still receives security updates. This is where it shows what the existing code can take.
    MeanwhileFunctions stay as users know them.
  3. 3
    Replace areas One area after another is rebuilt and takes over. Which one comes first is decided by the finding — not by the order in the menu.
    MeanwhileOld and new parts run side by side.
  4. 4
    Switch off what is left Whatever nobody calls any more is removed. Only then does maintaining two versions end.
    MeanwhileDay-to-day operation no longer notices any of it.
A conceptual illustration of the approach, not the timeline of a particular project. How many stages are needed, and how long they take, follows from the survey.

Three possible outcomes — and no fourth answer

After the survey there are exactly three honest answers:

  • Develop further: the structure holds, the basis can be updated, changes are possible at manageable cost.
  • Renew step by step: the application stays in operation, areas are replaced one after another. This is the most common route.
  • Build anew: where structure and data storage are such that every change brings more risk than benefit.

The third answer needs a justification with references, not a matter of taste. A blanket "that has to be rebuilt" without a review sells a project, not a solution.

What we need for it

  • The source code, with its version history if possible.
  • Access to an environment in which the application can be started — not necessarily the production environment.
  • The structure of the database. An export of the structure is usually enough; real records are not needed.
  • Someone who can answer the questions about the business side. Code shows what happens, not why.

What we expressly do not need is credentials for production systems by email. There are secure ways to share access, and we only ask for what the review requires.

Common misunderstandings

Usually yes. What matters is structure, data storage and how well the basis has been maintained — not age. There are carefully built old applications and very new ones that nobody can maintain.

Yes, where the finding shows that a change at that point is manageable. That is exactly what the survey is for: it says which interventions stay small and which do not.

Running and being maintained are two different things. Without security updates for PHP and the libraries in use, the risk grows without anything changing in day-to-day operation.

It postpones the start of implementation by days and prevents decisions that cost months.

Have your application reviewed

Describe briefly what it is about — the only required details are your email address and a few sentences about the task. Under "What is this about?" choose "Modernising PHP software".

Development enquiry

For development work: a new application, an extension, or taking over existing software.

Tell us briefly about your idea or your existing application. Technical documents and a finished specification are not needed for a first enquiry.

Which task should become easier, and for whom?
This is how we will reply.
Optional.

Optional details — useful, but not required

If you came from a project or service page, this is already selected.
Only if it exists. We do not need access for an enquiry.
For example an ERP system, a shop or an internal application.
"Not yet decided" is a valid answer.
Optional.
Optional. We need a phone number if you would like us to call back.

We use the information you provide to handle your enquiry. Please do not send passwords, access keys or confidential personal or customer data.

How we process the information you provide is set out in our privacy notice.

Read on first