Quick answer
Compare the PHP runtime used by web requests, required extensions, database compatibility and scheduled jobs on both hosts. Match the application’s supported requirements, not just its files or command-line PHP version. Prove the result on a protected preview before cutover.
Inventory the application, not just its files
Before moving a PHP site, list its application version, supported PHP release, extensions, database, writable paths, jobs and external services. Compare those requirements with the actual destination. Loading the homepage once is not a compatibility test.
DirectAdmin can support multiple PHP versions and extensions, but the exact versions and modules on the destination depend on that server and your entitlement. This guide records requirements before the move; changing the live PHP version has its own procedure.
Capture the source environment safely
In the source account, record the PHP version actually used by the website rather than the command-line default. List application-required extensions from its documentation or dependency file and compare with the runtime that handles web requests. Note database version, connection method, table collation and any extensions used by the application. Inventory cron or scheduled jobs and their expected working directories. Record outbound APIs, payment, mail, object storage and webhook endpoints with their owner, without copying credentials into the inventory.
Keep configuration secrets in an approved secure handover channel. A screenshot of a PHP information page may reveal sensitive paths and settings; use it only as a temporary controlled diagnostic and remove it afterwards.
Compare with the actual destination
Ask the destination operator which PHP releases and extensions are installed and which can be selected for this site. Compare each requirement with the actual target rather than a generic DirectAdmin capability list. If a required module, database version or filesystem permission is absent, record a decision: adapt the application, request a supported change, choose another destination or postpone. Do not select an unsupported old PHP version merely to make a legacy site start.
Check whether the application assumes local mail transport, a fixed server path or a writable directory that the new service does not provide. For a managed VPS, the agency owns application compatibility while the operator owns agreed platform components.
Test a representative preview and retain rollback
Deploy a safe copy to an authorised preview or staging route using the real hostname where needed. Test login, database reads and writes, scheduled work, a form, outbound integrations and error logs. Compare the result with the source environment and record each unresolved gap. Keep the original site and its current data available until the cutover and rollback decision are complete. If a critical dependency cannot be supplied or tested, stop the move rather than treating a working homepage as acceptance.
Example: the web runtime differs from the shell
An application may work in the browser on one PHP release while a scheduled command uses another. Record the web runtime and the scheduled command’s interpreter separately. If the application requires an extension for a form or image task, test that task on the destination; a plain homepage may never exercise the extension.
If a requirement is missing, name the affected task and choose an agreed solution before cutover: supply a supported module, adapt the application or postpone the move. Do not select an unsupported runtime merely to suppress the error.
Frequently asked questions
Is matching the PHP version enough? No. Extensions, configuration, database compatibility, filesystem paths and external integrations can still differ.
Should I enable every extension? No. Identify the application’s real requirements and ask the operator for supported, scoped changes.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.