How to Move a PHP Script to Another Server

Moving a script is not just "copy the folder by FTP". There are three parts: files including uploads, a MySQL dump, and new config credentials. Forget the dump and you get an empty site with nice layout. Forget files/ or uploads/ and cards lose images.

Do the move in one window: copy, deploy, switch DNS. Running two servers for a long time without synchronization ends with diverging orders and listings.

What to take from the old server

1. An archive of the whole document root. Not only PHP files; cache can be excluded if you are sure, uploads cannot.
2. Database dump: all tables with data, utf8mb4. Export and import details: MySQL dump migration.
3. Current access notes: database host, name, user. It is better to create a new password on the new server.
4. Cron jobs from the panel; they must be moved too.

Before archiving, you may clean temporary junk, but do not delete what you do not understand. Backup routine: PHP and MySQL backup.

Prepare the new host

Compare PHP and modules with the requirements. Create an empty utf8mb4 database and a user with permissions on it. The document root must point to the directory where the script will be unpacked.

On shared hosting, the domain is usually already attached to public_html. On a VDS, prepare the Nginx/Apache vhost; SSL can be enabled immediately or after testing by IP/hosts: SSL, Nginx + PHP-FPM.

Deployment

1. Upload the archive and unpack it into the site root. Check that index.php is exactly where the web server points, not one level above.
2. Import the dump into the empty database.
3. Write the new host, database name, login, and password into config. Do not bring local root/empty password values to production.
4. Set permissions for upload/cache: chmod.
5. Restore cron on the new host: cron.

If there is a white screen after migration, check error_log and database connection first, not another upload on top. Often the config still has the old localhost socket or old password. See database error and 500.

URLs in the database and mixed content

Many scripts store the full site URL in settings or content. After a domain change, images may still point to the old host. Update the URL in the admin area, if there is a "site address" field, and check several cards with media.

If HTTPS is enabled on the new server but content still has http links, the browser reports mixed content and payment forms or accounts suffer. Post-SSL check: SSL manual.

DNS and downtime

While testing the new server, you can map the domain in the hosts file on your machine and avoid touching public DNS. Once verified, lower TTL in advance, ideally a day before, and switch the A record.

Mail and external callbacks such as payments or Telegram use the public domain. After DNS switch, check webhooks and return URLs in payment dashboards.

Permissions and file ownership

On a new VDS, the archive often belongs to root while PHP-FPM runs as www-data. Symptom: "cannot upload image" and permission denied in the log. Change the owner to the pool user and return 755/644. On shared hosting, the panel usually normalizes ownership when uploading through the file manager.

Manual checks

• Homepage, internal clean URL page, search.
• Admin login and user account login.
• One database write: new listing, order, comment, or whatever the product has.
• One file upload.
• Form email if configured.

Local rehearsal before production is convenient on MicroServer; migration from local to hosting uses the same checklist.

Rollback

Keep the archive and dump from the old server until the new one has lived for a few days. DNS rollback plus restore from backup is faster than "fixing in place" an unknown issue. If stuck, contact support with product, old/new host, and error text, without passwords: how to write.

Mail and external services

SMTP passwords move with files; check that the new server can reach ports 465/587. Some VDS providers block outbound mail until verification. Payment webhook URLs are updated in payment accounts separately when the domain changes; a database dump cannot do that for the acquirer.

Telegram bots and API keys may also live in config or the database. Send a test notification after migration.

Reducing downtime

1. Prepare the new server and deploy a copy in advance.
2. Check through hosts.
3. Before the final switch, take a fresh dump or delta.
4. Import the delta and switch DNS.
5. Turn off old cron immediately.

For large databases, use final dump with --single-transaction and compression: MySQL migration. General backup routine: backup.

Character data and serialization

Blind search-replace in a dump to change domains is dangerous: serialized PHP strings store length. Replace http://old with https://new without recalculating length and options break, causing strange 500s. Change URLs through product tools or scripts that understand serialize. If a "domain replace in sql" causes a white screen, restore the dump.

Different panels

Moving from ISPmanager to ISPmanager is familiar. Moving from shared Apache to bare Nginx needs time for rewrite: Nginx. From one shared host to another, check database name prefixes and PHP path for cron: cron.

Target platform selection: hosting, VDS. SSL on the new host: SSL.

Local intermediate step

Sometimes production to local MicroServer to new VDS is convenient. Locally you can catch dump surprises without downtime. Stack: MicroServer, import: phpMyAdmin. PHP requirements must be compatible at all three points: requirements.

Final checklist

• DNS and SSL.
• Admin area, account area, test database write.
• An image from upload opens.
• Cron is alive, old cron is disabled.
• Mail and payment callback.
• Monitoring switched to the new URL: monitoring.
• Firewall on the new VDS is not forgotten: firewall.

Permissions after unpacking: chmod. Fresh installation if you choose not to bring old data: installation.