Moving a site between hosts sounds simple: copy files, import the database, point the domain at the new server. In practice the trouble comes from details such as a forgotten cron job, a different PHP version, mailboxes left on the old server or orders lost while DNS changes propagate. The order below lets you move step by step while the site stays online and a way back remains open.
1. Inventory the old host
- Sites, subdomains and their folders.
- Databases, users and character sets.
- PHP version, extensions such as
intlorimagick,memory_limitandupload_max_filesize. - Cron jobs and their schedules.
- Mailboxes, forwards and autoresponders.
- Every DNS record: A, CNAME, MX and TXT (SPF, DKIM, verification records).
Forgotten TXT records for Search Console or mail services are a common cause of broken verification or delivery after a move.
2. Lower the TTL in advance
A day or two before the move, drop the A record's TTL to 300 seconds so the switch spreads quickly. If the domain is managed in the sayt.uz cabinet, TTLs are edited in the domain's DNS section.
dig +noall +answer example.uz A
3. Copy the files
rsync sends only changed files on later runs, so run it once early and again just before the switch.
tar -czf site.tar.gz -C ~/www example.uz
rsync -avz --progress ~/www/example.uz/ user@203.0.113.20:~/www/example.uz/
4. Move the database
Set the character set explicitly so Uzbek and Russian text survives, and use --single-transaction for a consistent InnoDB snapshot without downtime. Then update credentials in wp-config.php or .env.
mysqldump --single-transaction --default-character-set=utf8mb4 \
-u old_user -p old_db > db.sql
mysql --default-character-set=utf8mb4 -u new_user -p new_db < db.sql
5. Test before touching DNS
Add the new IP to your own hosts file so only your browser sees the new server. Check key pages, admin login, search, forms and uploads. A certificate warning is expected at this stage. Remove the line afterwards.
# Windows: C:\Windows\System32\drivers\etc\hosts
# Linux/macOS: /etc/hosts
203.0.113.20 example.uz www.example.uz
6. Freeze content and switch
Pick a quiet time, put the old site into maintenance mode, run a final database export and import plus one more rsync, then change the A record or the nameservers. If you change nameservers, the new zone must already contain every MX and TXT record.
7. Mail and SSL
Create the same mailboxes on the new server and copy messages over IMAP with imapsync. Mail may keep arriving at the old server for hours after the MX change, so run the sync again later. Issue the SSL certificate once the domain points at the new server, since Let's Encrypt validates that.
imapsync --host1 mail.old-host.example --user1 info@example.uz --password1 '***' \
--host2 mail.example.uz --user2 info@example.uz --password2 '***'
Example: a furniture shop in Fergana
A Fergana furniture shop on WordPress and WooCommerce moved from a slow foreign host to a server in Uzbekistan. The developer lowered the TTL, copied files and the database on Friday and tested the catalogue, cart and checkout through the hosts file. On Sunday morning he enabled maintenance mode for half an hour, synced the database one last time and switched the A record. The old host was kept for another week, and late emails were copied across.
After the move
- Confirm
dig example.uz Aanddig example.uz MXreturn new values. - Check the certificate and the
httptohttpsredirect. - Make sure cron jobs exist and run on the new server.
- Send a test message from the site's form and check it is not marked as spam.
- Keep the old hosting for at least a few days as a fallback.