How to Migrate Your Website to a New Hosting Provider Without Downtime

Switching hosting providers worries many Philippine website owners, mostly because of the fear of taking the site offline. A well-planned migration can be completed with little or no visible downtime, as long as you also plan for data that changes during the move. This guide covers the process from first backup to final cutover.

Why Philippine Businesses Switch Hosting Providers

Hosting needs change as businesses grow. A plan that handled 200 visitors per month may struggle at 2,000. Slow page load times, frequent downtime during Philippine peak hours (evening and payday weekends), or support teams that respond in time zones far from Manila are common reasons to move.

If your site is already showing signs that your current plan can't keep up, read about signs your growing business has outgrown shared hosting before you start. Understanding the root cause helps you choose the right next plan.

Before You Start: Pre-Migration Checklist

• Confirm your new hosting account is active and the control panel is accessible
• Decide whether your site is static/read-only or accepts orders, bookings, submissions, or uploads
• Export your complete DNS zone, including A/AAAA, www, and mail records, and note your current nameservers and whether DNSSEC is enabled
• Download a full backup of all website files (public_html or equivalent)
• Export your database(s) from the current host (MySQL dump via phpMyAdmin or command line)
• List all email accounts and confirm whether email stays with an external provider or moves with your hosting
• Note custom PHP settings, cron jobs, or .htaccess rules in use
• Record active SSL certificates and plan how the new host will provide a valid certificate for your production hostname before cutover

Step-by-Step: How to Migrate With Minimal Downtime

1. Back up all files and your database on the current host Use your current host's backup tool, cPanel's Backup Wizard, or an FTP client to download the complete contents of your public_html folder. Export each database via phpMyAdmin: select the database, click Export, choose the SQL format, and save the file. Keep these backups on your computer and, ideally, external or cloud storage.
2. Upload files and import the database on the new host Log in to your new control panel. Create a new database and database user with the same name and password as the original (or update the database connection details in your site's config file later). Upload your files via FTP, cPanel File Manager, or your host's migration tool. Import the exported SQL file via phpMyAdmin on the new server. For WordPress sites, update the wp-config.php file if database credentials changed. This is only the initial copy; if your site keeps receiving data, you will sync again in Step 6.
3. Test the site on the new server before changing DNS Edit your computer's hosts file to point your production hostname (and www) to the new server's IP address. This is the preferred test because the site, redirects, and HTTPS behave as they will live. A temporary host URL (such as server123.hostprovider.com/~yourdomain) may not validate the complete site, since URLs, redirects, and certificates can differ. Before cutover, confirm the new host serves valid HTTPS for your production hostname, using your host's supported certificate issuance or a secure certificate transfer. Browse the site, submit a test form, check images and links, and verify any e-commerce or booking features. Fix issues before traffic moves over.
4. Set up and verify email before cutover If your email is hosted externally (for example Google Workspace or Microsoft 365), it is unaffected by a website move: keep its MX, SPF, DKIM, and DMARC records unchanged in the DNS you use after cutover. If email is hosted with your old web host and is moving, recreating mailboxes is only the first part. Transfer existing messages (via IMAP migration or your host's tools), confirm the relevant DNS and authentication records, and test sending and receiving. Monitor mailboxes on both servers during cutover, then run a final mailbox synchronization.
5. Prepare DNS and lower the TTL before cutover Note your current TTL (Time to Live), then lower it to 300–600 seconds (5–10 minutes) on the records you will change. Do this at least as long before cutover as the previous TTL, so caches holding the old value expire first. Keeping your current DNS provider and editing only the website records (A/AAAA for the root domain and www) is often enough. Changing authoritative nameservers is optional, needed only if the new host will manage your DNS. Record TTL does not control all nameserver-delegation caching, so nameserver changes can take longer to settle. If you change nameservers, first copy the complete DNS zone to the new nameservers and coordinate DNSSEC if it is enabled, so validation does not fail.
6. Run the final sync, then cut over DNS For a static or read-only site, update the A/AAAA and www records (or the nameservers, if you chose that route) once testing passes. For a site that accepts orders, bookings, submissions, or uploads, pause writes briefly, copy the latest database and uploaded files to the new host, verify them, and then switch DNS. Visitors can still browse, but writes are unavailable, so tell customers. Keep the old site read-only throughout DNS propagation, and enable writes only on the verified new site after the final sync. Visitors reaching the old site must receive a clear notice that orders and submissions are temporarily unavailable. Never leave two independently writable copies, since visitors reach different servers during propagation. Complex transactional sites are better moved through a managed or coordinated migration. A global DNS checker such as whatsmydns.net shows what some resolvers return; it does not prove every visitor has switched.
7. Cancel old hosting only after everything is verified Keep the old plan until you have verified the website, email (sending, receiving, and the final mailbox sync), HTTPS on the production hostname, and that final data such as orders and submissions exists on the new host. Overlap length depends on your previous TTL, any nameserver change, and traffic; check server logs for requests still reaching the old server, as a fixed 24–48 or 48–72-hour wait is not proof. Keep your final old-server backup for at least 30 days. To roll back, point records to the old host; caching means some visitors keep reaching the new server for a while, and data written there after cutover must be copied back first.

Common Mistakes That Cause Downtime During Migration

Frequently Asked Questions