Why so many businesses need to hire a PHP developer for old code
PHP powered a huge share of the web for two decades, so a lot of working business software was written in it: school fee portals, dealer ordering systems, property listing sites, clinic records, custom billing. Much of that code was written by one freelancer or a small shop that has since moved on.
The code usually still works, until something outside it changes. The host upgrades PHP, a payment callback changes format, a browser stops accepting an old cookie setting, or an SSL certificate renewal fails. Suddenly the system that ran quietly for years throws blank pages, and nobody on your side knows where to look.
That is the moment most people search for someone to hire. The good news: old PHP is usually rescuable. The language is backward compatible for most everyday code, the failures tend to cluster around a known list of removed functions, and a careful developer can bring an app up to date without a full rewrite. The bad news: careless fixes on a live server can lose data. That is why the rest of this guide is about method, not speed.
Signs your PHP application needs help now
Some problems can wait for a planned upgrade; others mean you should hire a PHP developer this week. Treat any of the following as urgent.
- The server runs a PHP version that no longer receives security fixes
- Blank white pages or “500 Internal Server Error” after a hosting change
- Log files full of deprecation warnings you have never read
- Queries built by joining user input into SQL strings
- Passwords stored as plain text or with old MD5 hashes
- Unknown PHP files appearing in upload folders
- Only one person has ever touched the code, and they are unreachable
- No backup has been restored and tested in the last year
Unknown files and plain-text passwords point to a possible breach, not just old code. In that case the first job is containment; our hacked website repair page covers those steps.
Which PHP version should your application run on?
Run a PHP release that still receives security fixes from the PHP project, and plan to move again before it expires. Each PHP release gets roughly two years of active support followed by a period of security-only fixes, after which it gets nothing.
As of late 2026, PHP 8.1 and every older version, including all of PHP 7 and PHP 5, are past end of life. PHP 8.2 reaches the end of its security support at the close of 2026, so an upgrade planned today should target PHP 8.3 or newer. You can always confirm the current schedule on the official “Supported Versions” page at php.net.
Many shared hosts in India still offer old versions in their control panel for compatibility, and some quietly default new accounts to them. The fact that your host still allows PHP 7.2 does not mean it is safe; it means the host is letting you choose the risk.
What a PHP code audit covers before any change
A proper rescue starts read-only. We copy the code and a recent database export to a private environment and change nothing on your live server until the audit is agreed.
Versions and dependencies
PHP version, framework and version, Composer packages (or hand-copied libraries), and which of those are abandoned.
Compatibility scan
Automated scans with tools such as PHPCompatibility for PHP_CodeSniffer and PHPStan, showing every line that will break on the target version.
Security review
Raw SQL built from input, missing output escaping, weak password storage, unchecked file uploads and exposed configuration files.
Data and integrations
Database engine and size, cron jobs, payment callbacks, SMS or email APIs, and anything that talks to other systems.
Server and deploy
How code reaches the server today, whether backups exist, and whether they actually restore.
The result is a short written report with a fix order and a price per step. You can hand it to anyone; it is useful even if you do not continue with us.
How a PHP 7 to PHP 8 upgrade actually runs
Upgrade on a copy, in steps, with checks at each step. Jumping straight from PHP 5.6 to 8.3 on the live server is how data gets lost.
We create a staging environment that mirrors production, then raise the PHP version one or two releases at a time. At each step we run the compatibility scan, fix what it flags, and click through the key user journeys: login, the main form, a payment, a report export. Tools like Rector can apply many mechanical changes automatically, but every automated change is reviewed by a person before it is committed.
Common fixes include replacing the old mysql_* database functions (removed back in PHP 7.0) with PDO or MySQLi prepared statements, removing each() and create_function() (both gone in PHP 8.0), declaring properties that were being created dynamically (deprecated in 8.2), and handling stricter behaviour where PHP 8 now throws errors instead of warnings.
When staging behaves, we schedule the switch for a quiet hour, take a fresh backup, deploy, and watch the error logs closely for the next few days.
Laravel, CodeIgniter or core PHP: each rescue is different
The framework decides how much of the upgrade is mechanical and how much is manual.
Laravel
Laravel ships a new major version roughly once a year, and each has an official upgrade guide. We move one major at a time, update Composer packages alongside, and replace packages whose authors stopped maintaining them. Skipping several majors at once multiplies the risk.
CodeIgniter 3
CodeIgniter 4 is a near-complete rewrite, not a drop-in update. Small CI3 apps can often be patched to run on newer PHP; larger ones are usually moved module by module to CI4 or Laravel while the old app keeps running.
Core PHP
Custom code with no framework is the most varied. Some is tidy and easy to upgrade; some mixes HTML, SQL and business rules in one file. We add structure gradually rather than rewriting everything at once.
WordPress
Usually the problem is an abandoned theme or plugin rather than WordPress itself. Our WordPress pages cover this separately.
If you are not sure which you have, send us the folder listing; the framework is usually obvious from its file structure.
Skills to check when you hire a PHP developer for legacy work
Legacy rescue needs a different profile from building new features. Look for patience with messy code and discipline around data, not only framework knowledge.
Ask a candidate how they would upgrade an app with no tests. A good answer mentions a staging copy, backups, characterisation checks on the main user journeys and small releases. Ask how they would find every SQL query built from user input. A good answer names static analysis and a manual search, then prepared statements. Ask what they do if the upgrade fails at go-live. A good answer describes a rollback plan written before the release, not after.
Also check the unglamorous skills: reading Apache or Nginx error logs, restoring a MySQL dump, configuring cron, handling character encoding when moving old latin1 data to utf8mb4, and writing a readable README. A developer who explains these in plain words is usually one you can rely on.
- Has upgraded a real app across at least one PHP major version
- Uses Git for every change, even small hotfixes
- Works on staging first and can describe a rollback
- Writes prepared statements by habit
- Documents what they changed and why
Should you upgrade the old PHP app or rebuild it?
Upgrade when the business logic is correct and the problems are mostly technical. Rebuild when the logic itself is wrong, undocumented and tangled, or when you need changes the old design cannot support.
A rough rule we use after an audit: if the fixes touch less than about a third of the code and the database structure is sound, upgrading is almost always cheaper and less risky. If nearly every file needs rewriting anyway, or the database has no relationships and duplicated data everywhere, a rebuild usually wins over a two-year horizon.
There is a middle path, sometimes called the strangler approach: keep the old app running, build new modules alongside it, and move users across one screen at a time. It costs a little more overall but avoids a risky single switchover. A full rebuild on our custom web app plan starts at ₹60,000; the audit tells you which route fits before you spend on either.
Security fixes a PHP developer should prioritise
Old PHP apps tend to carry the same handful of security holes. Fix these first, before cosmetic work or new features.
SQL injection comes top: every query must use prepared statements with bound parameters. Then passwords: move to password_hash() and password_verify(), rehashing users on their next login so nobody has to reset. Then output escaping on anything a user can type, to stop cross-site scripting. Then file uploads: check type and size, store outside the web root and never execute uploaded files. Then sessions and cookies: set secure, HttpOnly and SameSite flags and force HTTPS.
Finally, remove clutter attackers love: phpinfo() files, old backup copies such as config.php.bak, admin folders with default passwords, and unused scripts left from earlier developers. A clean codebase is easier to defend and easier to hand over. For a site-wide review beyond PHP, see website security.
How much does it cost to hire a PHP developer in India?
For rescue work, cost follows the audit, not a rate card. The same “upgrade to PHP 8” request can mean a day of fixes or several weeks, depending on code size, framework, test coverage and how many integrations must be re-checked.
Across the Indian market, hourly and monthly rates for PHP developers vary widely. Experience with legacy upgrades, availability for emergencies, whether testing is included and whether documentation is delivered all move the number. Compare offers on those terms, not only on the headline rate.
With us, each step in the audit plan is priced separately so you can approve the urgent part first. If the audit recommends a rebuild, it starts at ₹60,000 on our custom web app plan. Once stable, the app moves to monthly care from ₹8,000/mo, covering security updates, backups and small fixes. The first two months after any rebuild we deliver are free.
Documentation and handover: never be stuck again
Most legacy crises start with missing knowledge, so the rescue should end with that knowledge written down. You should be able to hand the project to any competent PHP developer next year.
Our handover includes: the Git repository in your account with a clean history of every change; a README explaining how to run the app locally; a list of environment settings (without secrets in the code); database schema notes; every cron job and what it does; each external integration with its account owner; server access details and the backup schedule; and a short log of what we changed during the rescue and why.
Credentials go to you in a secure way, not pasted into chat. If an earlier developer still has server or database access, we list those accounts so you can revoke them.
Legacy PHP in Indian businesses: common patterns
Certain patterns show up again and again in Indian PHP systems, and they shape how an upgrade is planned.
Many apps sit on low-cost shared hosting where you cannot install Composer or change server settings; moving them to a small VPS is often part of the fix. Older payment integrations were written against gateway APIs that have since changed; these need re-testing with UPI and card flows before go-live. Invoice modules often calculate GST with hard-coded rates and need care during any change. Hindi or regional text stored in latin1 columns shows up as question marks after a careless migration, so character sets are converted deliberately. SMS and OTP integrations may rely on sender IDs and templates registered under TRAI’s DLT rules, which must survive the move unchanged.
None of this is exotic, but a developer who has not seen it before can break a working system while “just upgrading PHP”.
Worked example: rescuing a dealer ordering portal
This is a hypothetical case to show the method, not a real client. A distributor runs a dealer ordering portal written in core PHP around 2014. Their host announces it will retire PHP 5.6 next month.
The audit finds mysql_* calls in forty files, MD5 passwords, a CSV export that uses each(), and a nightly cron that emails stock reports. We propose three priced steps. Step one: a staging copy, database functions moved to PDO prepared statements, passwords upgraded on next login. Step two: remaining PHP 8 fixes found by the scanner, the cron re-tested, a move to a small VPS running PHP 8.3 with daily off-site backups. Step three, optional: a new dealer dashboard built as a separate module.
The distributor approves steps one and two, the switch happens on a Sunday evening, and error logs are watched for a week. Step three waits until the next financial year. The portal keeps working throughout, and the owner now has a repository and a README instead of one person’s memory.
Hire a PHP developer remotely, anywhere in India
Legacy rescue is well suited to remote work: we need repository or FTP access, a database export and a video call, not a desk in your office. The same audit-first method and pricing apply in every city.
City pages describe local business context: Noida, Gurgaon, Mohali, Hyderabad, Chennai, Kolkata, Ahmedabad, Pune, Kanpur, Varanasi and Mangaluru.
Clients abroad with PHP systems built by Indian vendors years ago often come to us for the same rescue; billing is in USD through Wise, bank wire or PayPal. See hiring Indian developers from abroad.
Purana PHP software chal nahi raha? Seedhi baat
Agar hosting company ne PHP version badla aur aapka portal band ho gaya, ghabraiye mat. Zyadatar purana PHP code theek ho sakta hai. Pehle hum code ka audit karte hain, live server ko chhue bina, aur likh kar batate hain kya kharab hai aur kis order mein theek karna hai.
Har step ka alag price hota hai, toh aap pehle sirf zaroori kaam approve kar sakte hain. Poora kaam staging copy par test hota hai, backup lene ke baad hi live jaata hai. Code aapke apne Git repository mein rehta hai. Baad mein monthly care ₹8,000/mo se shuru hota hai.