Moving a live WordPress site to a new host is one of those jobs everyone puts off, mostly because the last time someone tried it, the site went down for six hours and half the contact form emails vanished. It doesn't have to go that way. With the right order of operations — and a little patience around DNS — you can move a WordPress site to SkyServer with visitors never noticing a thing.

This guide walks through a real zero-downtime migration: copying files and database, testing the new copy before anyone sees it, and cutting over DNS cleanly. It applies whether you're on shared cPanel hosting or moving up to a VPS.

Why Migrations Go Wrong

Almost every bad migration story comes down to one of three mistakes:

  • DNS was changed before the new site was actually tested and working.
  • The database was copied once, early on, and every order/comment/post made afterward on the old site got lost.
  • Email (MX records) got pointed at the new host before mailboxes existed there, and messages bounced for days.

The fix for all three is the same idea: build and verify the new site fully before you touch DNS, and copy the database again, right at the end, after a short freeze on the old site.

Step 1: Lower Your DNS TTL Early

Do this at least 24 hours before you plan to migrate. Every DNS record has a TTL (Time To Live) — how long resolvers cache it before checking again. If your A record's TTL is currently 14400 (4 hours) or 86400 (a full day), drop it to 300 (5 minutes) now. That way, when you actually flip the record later, the change propagates fast instead of leaving some visitors on the old server for a day.

In your current DNS zone (wherever it's hosted — your registrar or the old cPanel), find the A record for your domain and edit the TTL. You don't change the IP yet, just the TTL.

Step 2: Set Up the Site on SkyServer

Create the hosting account or addon domain in your new SkyServer cPanel, then move the site over:

  • Files: Zip up public_html on the old server (or the specific site folder) and download it, or use cPanel's Backup Wizard to generate a full account backup. Upload and extract it into the new account's public_html via File Manager or SFTP.
  • Database: Export the database with phpMyAdmin (Export > Quick > Go) on the old server. Create a matching database and user on SkyServer, then import the .sql file through phpMyAdmin there.
  • wp-config.php: Update the DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST constants to match the new database credentials. This is the single most common thing people forget, and it's why a freshly migrated site throws "Error establishing a database connection."

For sites over a few GB, or if you'd rather not do this by hand, SkyServer's support team can run the migration for you at no extra charge on most plans — open a ticket with your old hosting details and we'll handle the file and database transfer directly.

Step 3: Test the New Site Before DNS Changes

This is the step people skip, and it's the one that actually prevents downtime. You can preview the site on its new server using its IP address, without changing DNS at all:

  1. Find the new server's IP in your SkyServer cPanel welcome email or the account summary.
  2. Edit your local hosts file (/etc/hosts on Mac/Linux, C:\Windows\System32\drivers\etc\hosts on Windows) and add a line: 203.0.113.45 yourdomain.com
  3. Save it, flush your DNS cache, and open yourdomain.com in a browser. You're now looking at the new server's copy, while everyone else still hits the old one.

Click through the site. Log into wp-admin, submit a test order or contact form, check that images and CSS load, and confirm SSL isn't showing certificate errors (you can issue a free AutoSSL certificate on the new account even before DNS points there, as long as the domain resolves via your hosts file entry during the check — otherwise issue it right after cutover). Remove the hosts file entry once you're done testing.

Step 4: Freeze the Old Site and Re-Sync the Database

Content changes between your first export and cutover — new comments, orders, form submissions — will be lost if you don't account for them. Right before you flip DNS:

  • Put the old site into a brief maintenance/read-only mode, or at minimum stop new orders/signups for 10–15 minutes.
  • Export the database one more time from the old server.
  • Import that fresh export into the new SkyServer database, overwriting the earlier copy.

This is the only real "downtime" in the whole process, and it's measured in minutes, not hours — and it only affects new writes, not page loads.

Step 5: Cut Over DNS

Now change the A record to point at the SkyServer IP. Because you lowered the TTL in Step 1, most visitors will resolve to the new server within 5–15 minutes. A few ISP resolvers cache longer regardless of TTL, so expect stragglers for up to a few hours — this is normal and not something you can force faster.

Leave the old hosting account active and untouched for at least 48–72 hours. Anyone still resolving to the old IP during propagation will keep seeing a working site, not an error page, because you haven't deleted anything there yet.

Step 6: Don't Forget Email

If your mailboxes live on the same hosting account (common with cPanel email), moving the A record doesn't move mail on its own — MX records control where mail is delivered, and they can point somewhere entirely different from your website. Before cutover:

  • Recreate the same email accounts in the new cPanel with the same passwords, so mail clients keep working without reconfiguration.
  • Export mail via IMAP (or use cPanel's account transfer tool) if you need historical messages preserved.
  • Update MX, SPF, and DKIM records to point at SkyServer's mail servers only after mailboxes exist there and you've confirmed test mail delivers correctly.

Doing this out of order is how businesses lose a day of customer emails mid-migration.

Prevention: Making the Next Migration Easier

A few habits make any future move painless:

  • Keep TTLs reasonably low (1–4 hours) as a default, not just before a migration.
  • Use a staging subdomain for major changes so "test before you cut over" becomes routine, not a one-off scramble.
  • Take a full cPanel backup right before any migration, even if you're also doing a manual file/database copy — it's your rollback plan if something's missed.
StageWhat ChangesDowntime Risk
Lower TTLDNS zone onlyNone
Copy files & databaseNew server onlyNone
Test via hosts fileYour machine onlyNone
Freeze + re-sync databaseOld site read-only brieflyMinutes
DNS cutoverA record + MX recordsNone if tested first

Frequently Asked Questions

How long does DNS propagation actually take after cutover?

With a TTL of 300 seconds set in advance, most visitors switch over within 5–30 minutes. Some resolvers ignore TTL and cache up to 24–48 hours regardless, which is why you keep the old hosting account live during that window.

Will my SSL certificate carry over automatically?

No. You'll need to issue a new certificate on the SkyServer account, typically via AutoSSL in cPanel, which is free and usually completes within minutes once the domain resolves there (or immediately if you request it while testing through a hosts file entry).

Can I migrate a WooCommerce store without losing orders?

Yes, as long as you do the final database re-sync in Step 4 after freezing checkout on the old site. Orders placed between your first export and the freeze window are the only ones at risk if skipped.

What if I don't have SSH or SFTP access on the old host?

Use cPanel's built-in Backup Wizard to generate a full account backup as a downloadable archive, then upload that archive to the new SkyServer account and restore it there. No shell access is required for either side.

Does SkyServer offer free migration help?

Yes. On most SkyServer plans, our support team will handle the file and database transfer for you at no extra cost — open a support ticket with your current host's access details and expected migration window.