How to Move a WordPress Site to a New Host Without Breaking It

The migration itself is an afternoon. The part that costs people a weekend is everything attached to the domain: the TTL they never lowered, the mailboxes that stopped receiving, the cron job on the old server that quietly kept sending, and the cached copy of the old site that outlived the switch by three days. Move the files in the wrong order and you can recover. Rebuild DNS and email from memory and you cannot.

This is the order that works on any host, with any control panel, whether you are moving one brochure site or a store. The vendor-specific shortcuts are noted where they save an hour, but nothing here depends on them. If you are moving off a host you have already paid through the end of the month, use that month: the old server is your rollback target, and it is free until the invoice renews.

Write down what is attached before you touch anything

Inventory first, because the inventory is what a migration drops. Export the database, tar the files, and then write a list of everything that is not in either of them. The list is short and boring and it decides whether next Tuesday is quiet.

• Every DNS record at the registrar or DNS provider, in full: A, AAAA, CNAME, MX, TXT and any SRV. Screenshot the zone, then copy it into a plain text file. Screenshots do not survive a control panel redesign.
• Mailboxes and forwarders, with the exact addresses. SiteGround lists free email accounts on all three hosting tiers, and other hosts sell mail separately or not at all, so this row decides whether you are migrating a website or a company's correspondence.
• The SPF, DKIM and DMARC TXT records for the domain. If mail is going to keep flowing through the old provider for a while, the DKIM selector has to keep matching, which means copying the record, not regenerating it on the spur of the moment.
• Every cron job you added by hand. A plugin's scheduled task lives in the WordPress database and moves with it; a system cron entry that runs a backup script does not.
• Whether the current host signs outgoing mail, and how fast it lets a new account send. If you migrate on a Friday, the first person who notices a broken contact form is a customer.

Then take a backup you can restore, and test the restore somewhere that is not the live site. An untested backup is a wish. Local by Flywheel, or WordPress Playground in a browser tab, will take a copy of the database and a tarball and tell you within twenty minutes whether the archive is real.

Copy the site, then test it on a temporary URL

The mechanics are the same on every host. Create a database and a user at the new host, import the dump, upload the files, point wp-config.php at the new database, and give the install a working URL. Do not change the domain's DNS to do this. WordPress has supported a temporary address for years, and every reputable host gives you one.

On the new server, the two lines that matter in wp-config.php are WP_HOME and WP_SITEURL. Setting them makes the site answer on the host's temporary domain while the database still contains the real one, which is exactly what you want for testing and exactly what you must undo before launch.

For the database itself, use a search-and-replace that understands serialised PHP. Hardcoded old paths live inside serialised option values, and a naive text replacement changes the string length, which corrupts the value. WP-CLI does it correctly:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' \
  --all-tables --precise --dry-run

# drop --dry-run when the report looks right
wp cache flush
wp rewrite flush

If you would rather not touch SQL, three free tools do the same job without a terminal. The SiteGround Migrator plugin is the vendor's own, it is on wordpress.org, and it is current: version 2.1.2, updated 8 October 2026, tested to WordPress 7.1.3, 80,000 active installs. It pushes a site from any host into a SiteGround account, and SiteGround lists free migrations on all three of its hosting tiers, which means either the plugin or a support ticket. All-in-One WP Migration and Duplicator do the equivalent between any two hosts, including hosts that are not SiteGround. Pick one and read its restore path before you start, because the failure mode of all three is running out of PHP memory halfway through the import.

Change DNS last, and only after you have lowered the TTL

This is the step that turns a migration into an outage. DNS records are cached for the duration of their TTL, in resolvers you do not control, on the computers of people who will email you when the site looks wrong. A TTL of 86,400 means a change you regret takes up to a day to undo.

So lower it first. A day before the switch, set the TTL on the A record to 300 seconds and wait out the old value. Then, on the day, change the record, and the world catches up within minutes.

$ dig +nocmd wpsifero.com A +noall +answer
wpsifero.com.		60	IN	A	88.223.87.150
wpsifero.com.		60	IN	A	145.223.124.114

$ dig +nocmd +noall +answer siteground.com A
siteground.com.		360	IN	A	35.227.253.10

The number before IN is the TTL in seconds. A site on a low TTL cuts over in minutes and rolls back in minutes. A site on a day-long TTL does neither. Run that query the day before the move, not during it.

The switch itself is one line: point the A record at the new server's address, check that any AAAA record is either correct or absent, and leave the MX records alone unless the mail is moving too. If mail is moving, do it in this order: create the mailboxes and forwarders at the new host, verify SPF, DKIM and DMARC are published in the new zone, send and receive a test message in both directions, and only then change MX. Mail that arrives at a mailbox that does not exist yet is not recoverable by a resolver cache flush.

Know what breaks, and how to get back

Signs of a wrong destination are easy to name in advance. Images 404 because the database still points at the old uploads path. The admin login redirects to the temporary domain because WP_HOME is still set. The site serves an old page because the new host's cache was warmed before the content was final. Users see mixed content warnings because a hardcoded http:// URL survived the search and replace. Each has a one-line fix, and none of them is a reason to panic.

Rollback is the feature you build before you need it. Keep the old host paid and untouched for a week, keep the old DNS zone in a text file, and leave the TTL low until you are sure. If the site is wrong in a way you cannot fix in ten minutes, point the A record back at the old address, and the world returns to the working copy within the TTL you deliberately shortened. That is the whole trick, and it is the reason lowering the TTL is non-negotiable rather than best practice.

What this plan does not solve is email. Mail does not follow DNS instantly and it is not covered by a rollback you can reason about: messages sent to an address during the window are either queued or bounced, depending on the sender, and there is no undo. If you run mailboxes on the same account as the website, treat the email move as its own project with its own evening, and keep the old mailboxes receiving for at least a week after the site has moved. For a small site, moving the domain's mail to a provider you would keep anyway makes the next hosting migration somebody else's problem.

Where SiteGround fits, and where it does not

SiteGround is the destination in this article because it is the one whose numbers I have in front of me and whose migration path I have checked. Its WordPress hosting currently shows StartUp at $2.99 a month, renewing at $17.99, prepaid for twelve months and excluding VAT. GrowBig is $4.99 intro and renews at $29.99; GoGeek is $7.99 intro and renews at $44.99. All three list a free domain, free SSL, a CDN, daily backups, free email accounts, free site migrations and SSH and WP-CLI. Staging is on GrowBig and GoGeek, not on StartUp, which matters if you intend to test a migration properly rather than point your only copy of the site at a new server and hope. On-demand backups, private DNS and priority support are GoGeek features.

If you want the shortcut, this is where to buy it: SiteGround's WordPress hosting plans start at StartUp for $2.99 a month for the first year, and the same page shows the renewal price next to it. Buy GrowBig instead of StartUp if you need staging, because the difference is $2.00 a month on the introductory rate and it buys the one feature that makes a migration testable.

Advertisement · SiteGround

SiteGround stops being the right choice in three cases. If your site is a growing WooCommerce store with a large product table and unpredictable traffic spikes, shared hosting will hold you until it does not, and a managed plan with a published visit allowance is a better home. If you are consolidating several client sites and want one server you can size yourself, a cloud host where you choose the RAM is cheaper per site than three shared accounts.

Do it in this order on Monday

1. Export the database, tar the files, and write the DNS, mailbox and cron inventory to a text file.
2. Restore the archive somewhere that is not production and confirm it loads.
3. Lower the A record's TTL to 300 seconds and wait out the previous value.
4. Build and test the site at the new host on its temporary domain, with staging or a second install, until every page you care about works.
5. Change the A record, watch the site for an hour, and keep the old host alive for a week. Move mail last, as its own job.