Legacy PHP websites: separate runtime changes from database and hosting moves

The host changing PHP does not define the whole job

A host's runtime switch can expose a language incompatibility, missing extension or old database API. Moving the same application to another host adds filesystem, web-server, email and data-cutover questions. Quote those separately unless the agreed outcome genuinely includes all of them.

• Record old and target PHP versions and required extensions.
• Identify critical flows such as login, form submission, checkout and reporting.
• Keep the first redacted error after the host change.

Some old calls cannot be restored by configuration

The original mysql extension was removed in PHP 7.0. An undefined mysql_connect error therefore points to code that needs a supported API, not just a database password reset. PHP 8.0 adds further language and error-handling changes, so a successful home page cannot prove an old site's business behaviour survives.

• MySQLi and PDO_MySQL require deliberate API changes.
• Review queries, result handling, transactions and connection errors.
• Keep user-provided values parameterised; compatibility work should not introduce injection risk.

Test the same business result

Use an authorised copy with synthetic data to compare key reads and writes before and after the change. Inventory uploaded files, scheduled work and email as well as the database. A hosting rollback must account for writes after cutover; returning DNS or code to the old host does not reconcile two changing databases.

• Restore a backup in isolation before relying on it.
• Name the live switch owner and the data-write boundary.

What to send first

Send versions, host type, affected flow and a redacted first error. Do not send a cPanel login, database dump, password or confidential code. Compatibility repair and hosting migration remain enquiry-led scopes, not guarantees that every undocumented legacy feature can be preserved at a posted price.