Move a website without losing files: backup, copy, then point DNS

Part of our guide on difference cloud backup storage

The safest move never moves. It copies, proves the copy works, then points the address.

What you need before you move anything

Say you start the move on a Friday night and the new host asks for a file you did not pack. You pause while visitors see errors. A short checklist prevents that scramble and keeps every file accounted for.

You need access to both hosts, the domain DNS, and a place to store a full backup offline. That means hosting logins, FTP or file manager, database access like phpMyAdmin, and your registrar or DNS panel. Keep a notebook for new and old IP addresses.

You also need a way to test without changing the live site. A temporary URL from the new host or a quick hosts file edit does this. Add a plain text editor and a way to measure time, since TTL changes need hours to spread.

• Both hosting logins: old host and new host, with FTP or file manager and phpMyAdmin or similar
• DNS access: registrar or Cloudflare panel where A and CNAME records live
• Local storage: laptop or external drive with 2x your site size free, plus ZIP tool
• Test tools: new host temporary URL and ability to edit your computer hosts file
• Notes: old IP, new IP, database names, and admin passwords written down

What counts as a complete backup: files, database, and media/config to copy

Picture a WordPress blog with 800 images. You copy the theme folder but miss the uploads folder and the database. The new site loads with no posts and broken images. That is not a backup, it is a partial copy. We go through how to backup files step by step elsewhere on the site.

A complete backup is three parts together. All files in public_html or www, including hidden files like .htaccess and config such as wp-config.php. The database as a full SQL dump, not just a table. Media and config that live outside code, like wp-content/uploads, email forwarders, and cron jobs if you use them.

Files without the database give you a shell. Database without files gives you no images or plugins. You need both from the same point in time, ideally within minutes. Export the database, then zip files right after, so posts and uploads match.

Test the backup by opening it. Unzip the archive on your computer and check that uploads has recent images. Open the SQL file and confirm it is not empty and ends without errors. Store one copy locally and one in cloud storage. That is your rollback if anything fails. There is more on Duplicati backup keeps failing after large file added in a separate guide.

1. Log into old host file manager or FTP and compress the site root to ZIP including hidden files.
2. Export the database from phpMyAdmin using Quick export as SQL, or use your host backup tool.
3. Download both files to your computer and to a second location like Drive or Dropbox.
4. Unzip locally and spot check: recent uploads present, SQL file size looks right, config file included.

How and when to lower DNS TTL before the move to shorten propagation

Say you point DNS and visitors still hit the old host for a day. Orders go to the old database and vanish after you shut it down. That lag comes from TTL, the time resolvers cache your old address.

TTL tells DNS resolvers how long to remember an IP. Many domains sit at 14400 seconds to 86400 seconds (4 to 24 hours). Lower it to 300 seconds (5 minutes) 24 to 48 hours before you plan to switch. That window lets the old, longer TTL expire everywhere before you change the A record.

You lower TTL in the DNS zone, not in hosting. Open your registrar or DNS panel, find the A record for @ and www, and change TTL to 300. Do this at least a day before moving. Do not change the IP yet. You are only telling caches to forget faster. Before you commit to anything, it is worth looking at shrink vdi file size.

After the move and checks, you can raise TTL again to 14400 or higher to reduce lookups. Keep it low until you are sure the new site serves and propagation looks done, usually 48 to 72 hours after the switch. Short TTL is temporary.

1. Find where DNS lives: registrar, Cloudflare, or old host. Check the nameservers to be sure.
2. Edit the A record TTL for the root and www to 300 seconds. Save.
3. Wait 24 to 48 hours. Use this time to copy and test the site on the new host.
4. After a successful switch, raise TTL back to 14400 seconds after 2 to 3 days.

How to copy to the new host and verify on a temporary URL or hosts-file test

Picture you upload files and the homepage looks fine, but checkout fails because the database prefix changed. You would not want the public to find that. Testing on a private address catches it first.

Copy in this order: create the empty database on the new host, import the SQL dump, upload and unzip files, then update config to point at the new database. In WordPress that is wp-config.php with DB name, user, password and host. Keep the site in maintenance mode while you test. It helps to understand when deleted files are recoverable before going further.

Hostinger and many hosts give you a temporary URL like xxx.hostingersite.com or a preview link. That lets you click through pages, log into admin, and test forms without touching DNS. It is fast but sometimes misses domain-specific links or SSL. A hosts file test is stricter.

A hosts file edit makes only your computer think the domain points to the new IP. You see the real domain with real SSL on the new server, while everyone else still sees the old site. Use it to test checkout, login, and media. Clear cache between tests. That is the closest to live without going live.

1. On new host, create a new MySQL database and user, then import your SQL file via phpMyAdmin.
2. Upload the ZIP to the new host file manager and extract to public_html. Overwrite only the new empty install.
3. Update config file (wp-config.php or .env) with new DB credentials and save.
4. Test on temporary URL: homepage, 3 inner pages, login, one form, one media file.
5. Test via hosts file: add line new.IP.address yourdomain.com www.yourdomain.com, save, flush DNS, browse as normal.

When and how to switch DNS and keep the old host as instant rollback

Say you switch DNS at noon and the new site throws a 500 error at 12:05. If the old host is already deleted, you have downtime while you rebuild. If it is still live, you flip back in minutes. Before you commit to anything, it is worth looking at sync and backup differences.

Switch DNS only after tests pass and TTL has been low for a day. Change the A record for @ and www to the new IP address from your new host panel. Keep the old A record value written down. Do not cancel the old hosting yet. This is the copy-first, DNS-last order.

Propagation is not instant. With 300 seconds TTL most visitors move within minutes to an hour, but some ISP caches lag. Check from multiple places: your phone on mobile data, an online DNS checker, and dig or whatsmydns.net. When you see the new IP broadly, log into the new site on the live domain and place a test order or post.

Keep the old host as rollback for 48 to 72 hours. Freeze changes there or put it in maintenance so no new orders split across two databases. If something breaks, revert the A record to the old IP and you are back. After two quiet days, raise TTL and then cancel the old plan.

1. Confirm TTL has been at 300 seconds for at least 24 hours and tests pass.
2. In DNS panel, change A record for @ and www to new host IP. Save.
3. Verify propagation with DNS checker and by loading the site on phone data plus desktop.
4. Place a real test: login, submit form, check email arrives, view media.
5. Keep old host live 48 to 72 hours. If all good, raise TTL to 14400 and archive the old backup.

Common mistakes that lose files or create downtime

A move fails in predictable ways. People delete the old site too early, copy only files, or switch DNS before TTL is low. Each has a simple fix before it costs you.

Another trap is editing the live site during propagation. Half your visitors write to the old database and half to the new one. You end up with two partial datasets and no clean merge. Freeze content or enable maintenance on the old site right before you switch.

SSL and email get missed. The new host needs a fresh certificate and, if you use host email, matching MX records. Check those right after DNS points, not a week later when mail bounces.

• Deleting old host too soon -> keep it 48 to 72 hours and keep a local ZIP plus SQL copy
• Copying files only, no database -> always pair file ZIP with SQL dump from same hour
• Switching DNS with high TTL -> lower to 300 seconds 24 to 48 hours before the change
• Editing content during propagation -> freeze posts, orders, and comments until checks pass
• Forgetting hidden files -> include .htaccess, wp-config.php, and uploads in the ZIP
• Skipping SSL/MX check -> issue SSL on new host and verify MX records still point correctly

How to move website without losing files or downtime in the right order

Say you have a small shop that takes three orders a day. You cannot afford to lose one to a split database, and you cannot afford a blank screen at checkout. The order that protects you is copy, test, then point.

Start with a full backup and lower TTL. Copy files and database to the new host and prove the copy works on a temporary URL and a hosts file test. Only then change the A record to the new IP and watch propagation while the old host stays live for rollback.

If you want the manual path, use file manager and phpMyAdmin as described. If you want fewer steps, Hostinger offers unlimited free migrations and will copy files plus database for you, then you still test and point DNS yourself. That saves time on the copy step, but you still control TTL, testing, and when to cancel the old host.

Think of DNS like a street sign. You build the new shop fully, open it for a private walk-through, then you move the sign. Visitors follow the new sign within minutes because you lowered TTL, and the old shop stays open behind it until you are sure.

Questions people still ask

I have moved sites by zipping on the server and editing hosts for the final check, it catches the one broken path before users do.