# How to Migrate a WordPress Website Safely

- Link: https://offshorehosting.pk/how-to-migrate-a-wordpress-website-safely/
- Published: 2026-10-25T10:12:00+00:00
- Author: admin

# How to Migrate a WordPress Website Safely

Moving a WordPress site to a new host is one of the most common operations in web
hosting — and one of the most feared. The fear is justified: a migration touches
your files, your database, your URLs, and your DNS, and a mistake in any one of 
them can take the site offline or corrupt it silently.

The good news is that a safe migration is a procedure, not a gamble. Follow the 
sequence in this guide — backup, prepare, copy, test, switch, verify — and the move
becomes boring, which is exactly what you want.

## What a WordPress site actually consists of

Before you move anything, know what you are moving. A WordPress site has three parts:

 1. **The files.** Everything in the WordPress installation: core files, themes, plugins,
    and the uploads folder (your images and media). The uploads folder is usually the
    largest part.
 2. **The database.** Posts, pages, comments, settings, users, and most plugin data
    live in MySQL or MariaDB. The database is the part people most often forget or 
    corrupt.
 3. **The configuration.** The `wp-config.php` file holds the database credentials,
    the site URLs, and security keys. It is small, but the site will not run without
    a correct one.

A complete migration moves all three, and verifies all three at the destination 
before anything is switched off at the source.

## Step 1: back up everything, and verify the backup

Before you touch anything, take a full backup of the live site: files plus database.
Then verify it:

 * Check the backup file sizes are plausible — a database backup of a few kilobytes
   for a site with hundreds of posts means something is missing.
 * Download the backup to your own computer, not just to the server you are leaving.
   A backup stored on the server you are migrating away from is not a backup.
 * If your backup tool offers a verification or test-restore option, use it.

This backup is your rollback plan. If anything goes wrong later, you can restore
it and try again. Never start a migration without it.

## Step 2: prepare the destination

Set up the new hosting account and check the environment before you copy anything:

 * **PHP version.** The destination should run PHP 8.3 or newer (WordPress.org’s
   current recommendation). If the old host ran an older PHP version, check that
   your theme and plugins are compatible with the newer one — a plugin that worked
   on PHP 7.4 can break on PHP 8.3. Test this on staging, not on the live site.
 * **Database version.** MySQL 8.0 or MariaDB 10.6 or newer.
 * **PHP limits.** Check `upload_max_filesize`, `post_max_size`, `max_execution_time`,
   and `memory_limit`. A large site may need higher limits than the defaults to 
   import its database.
 * **SSL certificate.** Install the certificate at the destination before the switch,
   so the site works over HTTPS from the first moment DNS points at it.
 * **Create the empty database and user** at the destination, and note the credentials.

## Step 3: choose a migration method

There are three common approaches. All three work; choose the one that matches your
comfort level.

**A migration plugin.** Plugins such as Duplicator, All-in-One WP Migration, or 
UpdraftPlus (with its migrator) package the site into an archive, which you then
import at the destination. This is the easiest method for most people, and the plugin
handles the URL search-and-replace for you. Watch the size limits: free versions
often cap the archive size, and very large sites may need the paid version or a 
manual move.

**WP-CLI (command line).** If you have SSH access at both ends, WP-CLI is the fastest
and most reliable method: export the database with `wp db export`, copy the files
with `rsync`, import with `wp db import`, and fix the URLs with `wp search-replace`.
This is the professional’s choice, but it requires comfort with the command line.

**Manual (phpMyAdmin + FTP/SFTP).** Export the database from phpMyAdmin, download
the files by FTP or SFTP, upload them at the destination, import the database, and
update `wp-config.php`. It works, but the URL replacement must be done carefully—
a naive find-and-replace on the raw SQL can corrupt serialised data (WordPress stores
some settings as serialised PHP arrays, where the string length is part of the data).
Use a tool that understands serialisation, such as WP-CLI’s `search-replace` or 
a dedicated search-and-replace plugin, rather than editing the SQL file in a text
editor.

## Step 4: copy the site and test it before switching DNS

This is the step that separates a safe migration from a gamble: **test the site 
at the destination before you change DNS.**

How to test without changing DNS:

 * Use a temporary URL provided by the host, if one is available.
 * Or edit your computer’s hosts file to point the domain at the new server’s IP
   address. This lets your computer — and only your computer — see the new site 
   while the rest of the world still sees the old one.

Then test thoroughly:

 * The homepage and several inner pages load, with images.
 * The admin area (`/wp-admin`) works, and you can log in.
 * Forms submit correctly.
 * The store checkout works, if it is a store — place a test order.
 * Search works, and a few posts open correctly.
 * The site loads over HTTPS without mixed-content warnings.

Also check the PHP error log at the destination for warnings your old host may have
hidden. A plugin that throws deprecation warnings on PHP 8.3 will tell you now, 
while the old site is still live.

## Step 5: lower the TTL, then switch DNS

A day or two before the switch, lower the TTL on the domain’s A record (and AAAA
record, if you have one) to 300 seconds. This means that when you change the record,
resolvers around the world pick up the new address within minutes rather than hours.

Then update the DNS records to point at the new server’s IP address. Do not cancel
the old hosting yet.

**Warning:** do not change the nameservers and the hosting at the same time unless
you have to. If your DNS is hosted by a third party, keep it there and only change
the A record. If your DNS is hosted by the old host, move DNS first or make sure
the new host has a complete copy of the zone. Changing two things at once makes 
failures much harder to diagnose.

## Step 6: verify after the switch

After the DNS change, verify from the outside, not just from your own computer (
which may still have the old address cached):

 * Use a public DNS lookup tool to confirm the domain resolves to the new IP.
 * Load the site from a different network or a mobile connection.
 * Test the admin login, a form submission, and (for a store) a test checkout.
 * Check that email still works — especially if mail was hosted with the old provider.
   If your MX records pointed at the old host, you may need to update them, or move
   mail separately. See [How to Transfer a Domain Without Disrupting Email](https://offshorehosting.pk/blog/how-to-transfer-a-domain-without-disrupting-email/).
 * Check the SSL certificate is valid and auto-renewing.
 * Re-check scheduled tasks: WordPress cron jobs, and any server cron jobs that 
   ran on the old host, need to exist on the new one.
 * Update any hardcoded references to the old server: external services, APIs, webhooks,
   and CDN settings that pointed at the old IP.

Then watch the site for 24–48 hours. Keep the old hosting active for at least a 
week as a fallback — if something breaks, you can point DNS back in minutes.

## Step 7: clean up

Once the site has run correctly on the new host for a week, cancel the old hosting
plan, remove any temporary test URLs or hosts-file entries, raise the DNS TTL back
to a normal value (for example, 3600 or 86400 seconds), and take a fresh backup 
on the new host.

## Common mistakes

 * **Migrating without a verified backup.** The one time you skip it is the time
   you need it.
 * **Editing the database SQL by hand.** Serialised data breaks silently, and the
   damage shows up weeks later as missing settings.
 * **Switching DNS before testing.** If the destination has a problem, the whole
   world sees it at once.
 * **Forgetting email.** A site migration that breaks mail is a migration that failed,
   even if the website looks fine.
 * **Ignoring the PHP version change.** Moving from PHP 7.4 to 8.3 can break old
   plugins. Test before you switch, and have a plan to replace or update anything
   that fails.

## The bottom line

A safe WordPress migration is a sequence: back up and verify, prepare the destination,
copy the site, test it privately, lower the TTL, switch DNS, verify from the outside,
and only then cancel the old host. Skip the testing step and you are gambling; skip
the backup and you are gambling without a safety net. Done in order, the whole move
is uneventful — and uneventful is the goal.

Related reading: [How to Choose WordPress Hosting in 2026](https://offshorehosting.pk/blog/how-to-choose-wordpress-hosting-2026/),
[WordPress Caching Explained](https://offshorehosting.pk/blog/wordpress-caching-explained/),
and [How to Transfer a Domain Without Disrupting Email](https://offshorehosting.pk/blog/how-to-transfer-a-domain-without-disrupting-email/).
See our [WordPress hosting plans](https://offshorehosting.pk/wordpress-hosting/).

---

_Reviewed 25 October 2026. Prices, plan contents, and availability for Offshore 
Hosting plans are [TO BE CONFIRMED] — this article does not state them._

## Sources

 * WordPress.org — Requirements: https://wordpress.org/about/requirements/
 * WordPress.org — Hosting Handbook, server environment: https://make.wordpress.
   org/hosting/handbook/handbook/server-environment/
 * PHP.net — Supported Versions: https://www.php.net/supported-versions.php
 * Cloudflare — Onboard a domain (DNS setup): https://developers.cloudflare.com/
   fundamentals/manage-domains/add-site/