Your application still works. Orders come in, staff log in and exports run. Yet no one really knows who could step in tomorrow: the original developer has left the company, the agency has stopped providing maintenance or your supplier no longer responds.
The difficulties often begin before the first outage. No one can estimate the cost of a change, a hosting alert goes unanswered or access is missing when a service needs renewing. The business still has a useful tool, but its ability to maintain it has diminished.
When taking over a PHP application, the first goal is to regain that ability to act: understand what is running, be able to restore it and establish a reliable way to change it. The decision to modernise or rewrite comes later, once the risks and business rules are understood.
Start with what the business cannot afford to lose
Before discussing frameworks, identify the operations the application must keep supporting. What would happen if it became unavailable tomorrow morning? Could you process orders another way, retrieve customer details, prepare invoices or keep production running?
This conversation with users guides the handover. A slow dashboard and an incorrect accounting export carry different risks. The size of the codebase does not tell you how much the business depends on it either.
Consider an illustrative example: a small business uses a PHP application to receive enquiries, calculate a price and pass each case to its business management software. The public form appears to be the heart of the system. But the overnight job that transfers those cases may matter more: if it fails silently, staff continue working with incomplete data.
The new provider therefore needs to examine the whole process, including operations that never appear on a screen. That understanding helps identify the checks to prioritise and the people who will validate changes.
Recover access, then establish what it lets you do
FTP access is useful for retrieving files. It does not necessarily give you the database, server configuration, backups or control of the domain name. Similarly, an administrator account in the application may not be enough to bring it back online after an incident.
The initial information gathering should cover five areas:
- Code: the Git repository, available archives, production files and the dependencies they need to run.
- Data: the database, uploaded documents, external storage and backups.
- Operations: hosting, domain, configuration, scheduled tasks and the deployment procedure.
- Connected services: payments, email, CRM, APIs and their associated billing accounts.
- People and business context: key users, known incidents, deadlines and existing documentation.
For each item, establish who controls the account, who can make changes and what remains inaccessible. Share credentials through an appropriate secure channel, never in a public request or the code repository.
Password and API key rotation also needs planning. Changing a key without identifying the systems that use it can disrupt payments or synchronisation. Replace credentials with a verification plan, rather than changing everything at once without knowing the impact.
A takeover is still possible without Git, but some of the history is missing
A folder retrieved from the server can provide a starting point. You still need to establish whether it contains the complete application: some files may be generated, stored elsewhere or depend on configuration specific to that machine. Fixes may also have been made directly in production without being reflected in an older archive.
The approach is to preserve a secure snapshot of the existing system, then compare the available versions. Configuration containing credentials and user data stay out of the new repository. A Git history can then begin from an identified baseline: it will track future work, but it cannot reconstruct past decisions. The official Git documentation clearly distinguishes creating a repository from obtaining a copy of an existing one.
PHP libraries present another potential pitfall. If the project uses Composer, the composer.lock file records the exact dependency versions selected. The Composer documentation explains that installing from this file preserves those versions, whereas an update can change them. Recreating the environment and upgrading its components are therefore two separate tasks.
The absence of Git does not make a rewrite necessary. It increases uncertainty and calls for greater care when establishing the first reliable baseline.
Audit, takeover and rewrite: three different decisions
An audit supports decision-making. It assesses what is accessible, what threatens continuity and what prevents further development. The findings should distinguish confirmed observations, incomplete checks and proposed actions. A long list of defects with no order of priority is of little use to a business owner.
The takeover establishes the ability to operate the application: restore a copy, understand essential processes, prepare a change and deploy it with appropriate checks. It may include urgent fixes. Its scope should distinguish this initial work from ongoing maintenance.
The rewrite replaces all or part of the system. It may be appropriate if a component cannot be recovered, requirements have changed substantially or the existing system's limitations are holding the business back. But it still requires identifying business exceptions, migrating data and organising the switchover. Choosing newer technology does not remove that work.
The age of PHP or the framework is part of the assessment. An end-of-life release is no longer supported by the PHP project; the official supported versions schedule lets you check its status. This warrants an upgrade plan, with urgency also determined by the application's exposure and the risks identified. Moving to the latest version needs preparation and testing.
An indicative timeline for the first 30 days
The following timeline provides checkpoints for decisions. It assumes access is available and the application can be examined. A major outage, a large database or missing accounts may change the order and duration of these phases. It is not a promise to complete the takeover in one month.
Days 1–3: secure the system and define the scope
The team gathers access details, identifies critical operations and preserves a copy of the code, data and necessary configuration. It examines backups and immediate alerts. You should be able to answer two questions: what can be recovered today, and where is there still a risk of data loss or disruption?
If the application is already down, restoring service takes priority. Any interventions are recorded so there is a trace of what was changed during the emergency.
Days 4–10: recreate and observe
An isolated copy lets the team verify that the system can be rebuilt. It must prevent real emails, payments and writes to production systems. The data used is limited or masked as needed.
Restoration often reveals forgotten dependencies: a PHP extension, an external directory, an email service or a program run by the server. An archive that looks complete may not be enough to restart the application. The expected result is a repeatable procedure, with any limitations documented.
Days 11–20: check data flows and prioritise fixes
The team follows the selected operations with users: creating a case, changing its status, exporting data or sending it to a partner. It also observes automated tasks and errors. A few targeted checks of these workflows provide a safety net before the first fixes.
Every intervention needs an expected outcome and an associated check. For a data transfer, that may mean verifying not only that the request was sent, but that the recipient received the correct case without duplicates.
Days 21–30: choose a direction and arrange ongoing support
The review distinguishes urgent issues addressed, remaining risks and possible improvements. It specifies who monitors incidents, how requests are prioritised and how changes will be delivered.
The right outcome may be stabilisation supported by a maintenance and modernisation programme, a gradual overhaul of a module or a replacement study. You should have clear options, including their dependencies and the uncertainties that still affect the budget.
What affects cost and timing
Two applications with the same number of screens can require very different levels of effort. Cost depends particularly on the ability to recreate the environment, the number of connected services, data quality and whether users are available to validate the business rules.
A project with no documentation but a consistent repository and a test environment may be easier to take over than a well-presented one whose server contains changes that cannot be found anywhere else. Availability requirements also increase the preparation needed for each change.
A sound proposal defines the scope of the initial assessment, its deliverables and the decision it will inform. Subsequent work can then be estimated against a verified scope. The proposal should identify unresolved assumptions: access to obtain, behaviour to confirm and volumes to measure. This separation allows useful initial work to begin without pretending the entire takeover is known in advance.
Preserve business rules before replacing the technology
Users' knowledge complements what the code reveals. An unusual rule may reflect a commercial agreement, an accounting constraint or a necessary exception. Removing it because it appears poorly designed may introduce a regression that is hard to detect.
The business SaaS platform featured by WEVE brings together a data model, business rules, imports, partner data flows, exports and ongoing maintenance and development. This published case study concerns the design and evolution of a Laravel platform. It illustrates how closely these functions are connected: replacing a process requires understanding the data it receives and the data it supplies to other modules.
For Laravel applications, our guide to taking over a Laravel application without rewriting everything explores the framework-specific questions in more detail. The approach described here also applies to custom PHP code or another framework: start with how the application actually works, then prepare changes that can be verified.
Prepare for your first conversation with WEVE
You can start even if your information is incomplete. Describe what the application does, who uses it, why maintenance stopped and which deadline is causing concern. Add a list of the access you have and any known incidents. Do not send passwords at this stage.
We can define an appropriate assessment, then a takeover plan based on what we find. The aim is to regain a tool you can operate, develop and entrust to a provider with clear responsibilities.
Need a new provider for your PHP application?
