How long does it take to assess an inherited PHP application?

About two weeks for a system of any real size — not to fix anything, but to know what you own. By the end you should be able to state plainly what runs where, what happens when it breaks, how much is covered by tests, and which parts nobody can change without holding their breath. Until you can answer those four, you cannot cost any decision about the codebase, including the decision to leave it alone.

Should we rewrite a legacy PHP application or maintain it?

Rewrite is almost always the more expensive answer and it is usually reached for too early. The better first question is narrower: can this be safely changed? A codebase that runs locally, has a reproducible environment and some test coverage can be improved incrementally, which is cheaper and less risky than a rewrite. Reach for a rewrite when the constraint is architectural rather than cosmetic — not because the code is unfamiliar.

What is the biggest risk in an inherited codebase?

Other systems writing to the same database. Bad code is visible and fixable; a cron job and a reporting tool that both write to the tables your application owns are not, and they are what turns a safe refactor into an outage. Finding every writer outside the application is the highest-value hour of the whole assessment.

What if we cannot get the application running locally?

That is the finding, and it is a significant one. It means every change since the last working environment was made directly against a live server and nobody has been able to test anything safely for a long time. The first deliverable is then a reproducible environment rather than a feature, because until one exists nothing can be verified.

Inheriting a Legacy PHP Application: The First Two Weeks

Someone leaves, an agency relationship ends, or a system quietly becomes business-critical without anyone deciding it should be. Now a PHP application nobody currently understands is running something that matters, and the question is what to do about it.

The instinct is to ask “should we rewrite it?” That is the wrong first question. The right one is narrower: can this be safely changed? Everything else follows from the answer.

The short answer

Two weeks is usually enough to answer it. Not to fix anything — to know what you own.

By the end you should be able to say, in plain language: what runs where, what happens when it breaks, how much of it is covered by tests, and which parts nobody can touch without holding their breath. If you cannot say those four things, you cannot cost any decision about it.

Get it running first

Before reading a line of code, get the thing running locally.

This sounds procedural. It is the single most informative test in the whole assessment, because the time it takes is a direct measure of how the project was maintained:

An hour: there is a README, dependencies are declared, and someone thought about the next person.
A day: normal for an older application. Some undocumented services, a config file to reconstruct.
You cannot: that is the finding. It means every change since the last working environment has been made directly against a live server, and nobody has been able to test anything safely for a long time.

That last case is more common than people expect, and it changes the shape of the work. The first deliverable is not a feature — it is a reproducible environment, because without one nothing else can be verified.

The questions that actually matter

Once it runs, five things determine whether the codebase can be worked on safely.

1. What PHP and framework version is it on?

This sets the floor for everything. An application on an unsupported PHP version is not receiving security patches, and the upgrade is rarely one step — it is a chain of dependency bumps where each one moves something else.

For Laravel specifically, the distance between versions matters more than the number. Two majors behind is routine. Six is a different project.

2. Where does the data live, and who else touches it?

The riskiest legacy systems are not the ones with bad code. They are the ones where three things write to the same tables — the app, a cron job, and a reporting tool somebody built in 2019 that everyone forgot.

You are looking for writers outside the application. They are what turns a safe refactor into an outage.

3. What is the test coverage, honestly?

Not the percentage. The question is whether the critical paths have any coverage at all — checkout, authentication, whatever the money or the compliance runs through.

A codebase with 20% coverage concentrated on the payment flow is far safer to change than one with 60% spread across model getters.

4. How does deployment work?

If deployment is a person copying files, every change carries the risk of a partial deploy, and rollback is a manual reversal. If there is a pipeline, you can move fast.

This is usually the cheapest thing to fix and the one that most improves everything after it.

5. What did it diverge from?

Legacy applications rarely match their own documentation. Where the build has drifted from what was specified is where the surprises live — the feature that was scoped, half-built, and left reachable by URL.

Rewrite versus refactor

The rewrite is the most expensive recommendation available, and it is right less often than the people pitching one suggest.

A rewrite is defensible when the framework is unsupported and the domain logic is genuinely small, or when the system cannot do something the business now needs and the architecture forecloses it. It is not defensible because the code is ugly, or because the current team would have built it differently.

The argument against is usually underestimated in one specific way. A rewrite has to reproduce every behaviour the current system has, including the ones nobody documented and some the business has forgotten it depends on. Those behaviours are discovered during the cutover, at the worst possible moment. The old system, meanwhile, keeps needing changes while the new one is built — so you pay for two.

The middle path is almost always better: stabilise, get tests around the parts that matter, then replace piece by piece behind the existing interface. Slower on paper, and far less likely to end in a rollback.

What “stabilise” means concretely

If the assessment says keep it, the first phase is narrow and unglamorous:

A reproducible local environment and a deployment that is not manual
Dependency and PHP version brought to something supported
Tests around the two or three paths that would hurt most if they broke
Errors reported somewhere a human sees them

None of that adds a feature. All of it is what makes the next six months of features possible, and it is the phase most likely to be skipped by whoever is under pressure to show progress.

The one thing worth doing first

Establish what you actually own.

Repositories, hosting, domains, DNS, third-party accounts, app store listings — and whether you are contractually entitled to them. When a relationship has ended badly, that question is often more urgent than the code, and it is frequently the most valuable outcome of the first week regardless of who ends up doing the work.

If you have inherited something and want a plain assessment of what state it is in before committing to anything, that is what our project rescue work is — including the outcomes where we say it does not need a rebuild.