Legacy PHP modernisation.
Inherited a PHP codebase nobody understands? That is fixable.
There is a specific situation I get called about often: a business depends on an application, the developer who built it is long gone, it runs on a PHP version that stopped getting security patches years ago, and nobody dares change anything. A full rewrite is quoted, priced at six figures, and shelved. That is rarely the right answer — incremental modernisation almost always is.
What’s included
- Codebase audit: what it does, where the risk is
- Security review and fixing SQL injection, XSS and file-upload holes
- PHP version upgrade with compatibility work
- Incremental refactoring while the application stays live
- Adding logging and monitoring so failures are visible
- Documentation so the next person is not in the same position
- Dependency and server modernisation
Why not just rewrite it?
Rewrites of working systems fail more often than they succeed. The existing application encodes years of business rules nobody wrote down, and you only discover them when the replacement gets them wrong. Rewrites also mean a long period paying for development with no benefit delivered. Incremental modernisation gives you improvement continuously and lets you stop when it is good enough.
Security first
Old PHP applications commonly have unparameterised queries, unescaped output, uploads that accept anything, and sessions that can be fixated. These are the first things I fix, because they are the ones that can end your business rather than merely annoy your users.
Making it observable
You cannot maintain what you cannot see. Early on I add structured logging and error reporting so problems surface as alerts rather than customer complaints. This usually reveals issues that had been happening silently for years.
Common questions
How old is too old?
I have worked on PHP 5.x codebases. Older versions mean more compatibility work in an upgrade, but the approach does not change.
Can you work without documentation or the original developer?
Yes — that is the normal situation. I read the code and the database, and where necessary observe behaviour in a safe environment to establish what it does.
Will the site go down during this?
No. Work is done on a separate environment and deployed in controlled steps, with a rollback path for each one.
What does the first engagement look like?
Usually a fixed-price audit: I review the codebase and infrastructure and give you a written assessment of risks, priorities and effort. You then decide what to do with it, with no obligation to continue.
Have a project in mind?
Tell me what you're building and roughly when you need it. I reply to every genuine enquiry within one working day.