Planning a WordPress site migration: a checklist

Planning a WordPress site migration means deciding exactly what will move, where it will move, what must change during the transfer and how the original site can be restored if something goes wrong.

A migration can look deceptively simple:

Old server
↓
Copy files
↓
Copy database
↓
New server
↓
Done?

That sequence describes only the physical transfer.

A real WordPress migration can also involve:

• DNS;
• domains;
• HTTPS certificates;
• database credentials;
• filesystem paths;
• stored URLs;
• serialized data;
• server configuration;
• PHP versions;
• scheduled tasks;
• email delivery;
• caching;
• CDN configuration;
• redirects;
• SEO signals;
• external APIs;
• payment callbacks;
• forms;
• background jobs;
• deployment and rollback procedures.

A better migration model is:

Audit
↓
Plan
↓
Back up
↓
Prepare destination
↓
Test
↓
Freeze or synchronize changing data
↓
Transfer
↓
Update environment-specific configuration
↓
Switch traffic
↓
Validate
↓
Monitor
↓
Keep rollback available

This WordPress site migration checklist covers that complete process, from the first inventory of the existing installation to post-launch validation.

What counts as a WordPress site migration?

A WordPress migration is any controlled movement of a site from one environment, location or URL structure to another.

Common examples include:

• moving to a new hosting provider;
• moving to a new server;
• changing the production domain;
• moving from a subdomain to the root domain;
• moving from a subdirectory to the root;
• moving from HTTP to HTTPS;
• moving from staging to production;
• moving production to a new infrastructure stack;
• cloning production into staging;
• moving a local development site online;
• moving into or out of WordPress Multisite.

The official WordPress migration documentation also highlights an important distinction: moving files and the database is not sufficient when the site’s domain or location changes, because references to the old location can remain stored inside the database.

Start by defining the exact migration

Before touching the source site, write down the migration in one sentence.

For example:

Move:

https://example-old.com

from:

Hosting Provider A

to:

Hosting Provider B

while changing the canonical domain to:

https://example.com

Or:

Move:

production.example.com

to:

a new server

without changing:

domain
URL structure
WordPress version
theme
plugins

Those are very different migrations.

The first requires URL replacement, redirects and SEO planning. The second may require none of those things.

Separate infrastructure migration from URL migration

A useful distinction is:

Infrastructure migration

old server
↓
new server

domain stays the same


URL migration

old URL
↓
new URL

domain or path changes

A project can involve either one or both.

If the domain or URL structure changes, read How to Migrate WordPress URLs Safely before performing database replacements.

Step 1: Inventory the current WordPress installation

Before planning the destination, understand the source.

Record at least:

• WordPress version;
• PHP version;
• database engine and version;
• active theme;
• child theme;
• active plugins;
• must-use plugins;
• drop-ins;
• custom code;
• database size;
• uploads size;
• total filesystem size;
• table prefix;
• scheduled tasks;
• external services;
• DNS configuration;
• CDN configuration;
• email configuration;
• caching architecture.

Do not discover an undocumented dependency after DNS has already been switched.

Step 2: Record the WordPress version

The destination should be able to run the site’s current WordPress installation before you start combining migration with unrelated software upgrades.

Changing:

hosting
+
PHP
+
WordPress
+
database version
+
plugins
+
theme

during one migration creates a much larger troubleshooting surface than changing only the infrastructure.

When possible, separate:

Migration
↓
Validation
↓
Software upgrades

unless the migration itself exists specifically to support an upgrade.

Step 3: Record the PHP environment

Check the PHP version used by the source site and the version available at the destination.

Also review relevant PHP configuration such as:

• memory_limit;
• upload_max_filesize;
• post_max_size;
• max_execution_time;
• max_input_vars;
• required PHP extensions.

A site that works correctly under one PHP configuration may expose previously hidden incompatibilities after migration.

Step 4: Audit plugins before migration

Create a list of active plugins and identify what each one actually does.

Pay particular attention to plugins responsible for:

• caching;
• security;
• SMTP;
• forms;
• payments;
• SEO;
• redirects;
• backups;
• image optimization;
• object caching;
• CDN integration;
• scheduled jobs;
• external APIs.

Server-specific plugins may require reconfiguration or removal at the destination.

For a structured plugin review, see Auditing WordPress Plugins on a Client Site.

Step 5: Identify custom code

Do not assume all site functionality lives inside ordinary plugins.

Check:

wp-content/themes/
wp-content/plugins/
wp-content/mu-plugins/
wp-content/uploads/
wp-content/*.php
wp-config.php

Also look for:

• custom cron scripts;
• server-level scripts;
• deployment scripts;
• custom Nginx rules;
• custom Apache rules;
• environment variables;
• server-side redirects.

Step 6: Audit the WordPress database

The database is often the most migration-sensitive part of a WordPress site.

WordPress Core uses a known set of tables, but plugins and custom development can add many more.

Before migration, determine:

• database size;
• table count;
• table prefix;
• largest tables;
• custom tables;
• obsolete tables;
• storage engine;
• character set;
• collation;
• unusually large option data.

The WordPress Database Structure, Explained provides useful context for understanding the data being moved.

For migration-specific preparation, use Preparing a WordPress Database for Migration.

Step 7: Inspect custom database tables

Do not assume every table with the WordPress prefix belongs to WordPress Core.

Plugins commonly create tables for:

• logs;
• analytics;
• forms;
• queues;
• security events;
• ecommerce;
• SEO data;
• scheduled actions;
• custom business data.

TheOneWP’s Database Manager can help inspect database tables, structures and stored records before migration work begins.

Step 8: Decide whether database cleanup belongs in the migration

A migration may reveal years of accumulated database bloat.

That does not automatically mean migration day is the best moment to delete it.

Separate:

Required migration work

from

Optional database optimization

If cleanup is necessary, understand the data first. WordPress Database Bloat, Explained covers common sources of unnecessary database growth.

Step 9: Measure the filesystem

Record the size of:

• WordPress Core;
• themes;
• plugins;
• uploads;
• cache directories;
• backup directories;
• logs;
• custom files.

This matters because a 700 MB WordPress site and a 90 GB media-heavy site require very different transfer strategies.

Step 10: Identify files that should not be migrated

Not every file on the source server belongs in the destination.

Possible examples include:

• old backups;
• cache files;
• temporary archives;
• debug logs;
• obsolete staging copies;
• server-generated temporary files.

Do not copy ten historical site backups inside wp-content and then wonder why the migration archive is five times larger than the website.

Step 11: Create a complete pre-migration backup

Before making migration-related changes, create a recovery point.

A complete migration backup normally includes:

Database
+
wp-content
+
configuration
+
custom server files
=
recoverable site

TheOneWP’s Backup Manager can create complete, database-only and files-only backups before migration-related maintenance.

The important word is recoverable.

A backup archive that has never been verified is evidence that a file exists, not evidence that the site can be restored from it.

Step 12: Store the backup separately

Do not keep the only pre-migration backup on the server you are about to modify or decommission.

Use an independent destination such as:

• another server;
• remote object storage;
• secure local storage;
• dedicated backup infrastructure.

The migration should remain recoverable even if the source hosting environment becomes unavailable.

Step 13: Verify the backup

Before proceeding, confirm:

• the database export exists;
• the database export is not empty;
• the expected files are present;
• uploads are included;
• custom code is included;
• configuration files are included where required;
• the archive can be opened;
• the restore procedure is understood.

The official WordPress upgrade documentation similarly emphasizes creating and verifying backups before significant changes.

Step 14: Define the rollback plan before migration

Do not invent the rollback procedure after the new site has failed.

Write it down before launch.

If migration fails:

1. Stop writes to destination
2. Restore original DNS or routing
3. Confirm old server is available
4. Restore database if source was modified
5. Verify source site
6. Reopen traffic
7. Investigate failure

The exact sequence depends on the migration architecture.

Step 15: Define objective rollback criteria

Decide what constitutes a failed migration.

For example:

Rollback if:

site produces widespread 500 errors
checkout cannot complete
authentication fails
critical forms fail
database import is incomplete
media library is missing
production data is inconsistent

Minor cosmetic problems may be repairable after launch.

Loss of transactions or broken authentication is a different category.

Step 16: Prepare the destination environment first

Do as much work as possible before touching production.

The destination should already have the required:

• web server;
• PHP runtime;
• PHP extensions;
• database server;
• filesystem permissions;
• SSL capability;
• caching services;
• object cache;
• scheduled-task configuration;
• security rules.

Step 17: Compare source and destination architecture

Document differences explicitly.

SOURCE

Apache
PHP 8.2
MariaDB
Redis
Local filesystem


DESTINATION

Nginx
PHP 8.4
MariaDB
Redis
Object storage

Every difference is something that may affect behavior.

Step 18: Check filesystem permissions

The web server must be able to read the WordPress installation and write to the locations that require it.

Check:

• ownership;
• directory permissions;
• file permissions;
• uploads permissions;
• cache directories;
• temporary directories.

Do not solve permission problems by making the entire WordPress installation globally writable.

Step 19: Prepare the destination database

Before import, confirm:

• database name;
• database user;
• database password;
• database host;
• character set;
• collation;
• available storage;
• required privileges.

The destination credentials will normally need to be reflected in wp-config.php or environment-specific configuration.

Step 20: Understand wp-config.php before copying it blindly

wp-config.php can contain far more than database credentials.

It may define:

• DB_NAME;
• DB_USER;
• DB_PASSWORD;
• DB_HOST;
• WP_HOME;
• WP_SITEURL;
• debugging configuration;
• memory limits;
• environment identifiers;
• custom paths;
• security constants;
• proxy configuration.

The official wp-config.php documentation explains the configuration file and the behavior of URL constants such as WP_HOME and WP_SITEURL.

Step 21: Determine whether the domain changes

Write down the source and destination URLs exactly.

SOURCE
https://old.example.com

DESTINATION
https://www.example.com

Pay attention to:

• HTTP versus HTTPS;
• www versus non-www;
• subdomains;
• subdirectories;
• trailing paths.

Step 22: Decide the canonical production hostname

A migration is a good moment to eliminate ambiguity about the canonical hostname.

For example:

http://example.com
http://www.example.com
https://www.example.com

↓

https://example.com

Choose the intended production version and redirect alternatives consistently.

Step 23: Check home and siteurl

WordPress commonly stores two important URL values:

home
siteurl

They are related but represent different concepts.

They may also be overridden in wp-config.php through:

WP_HOME
WP_SITEURL

Do not assume the values visible under Settings are necessarily the only source of URL configuration.

Step 24: Inventory stored URLs

WordPress stores URLs in many places beyond the two main options.

Possible locations include:

• post content;
• post metadata;
• options;
• widgets;
• menus;
• page-builder data;
• custom fields;
• theme settings;
• plugin configuration;
• CSS;
• custom database tables.

If the domain changes, those references need a deliberate migration strategy.

Step 25: Do not use naive SQL replacement

WordPress databases can contain PHP serialized data.

A serialized value can contain information about string length.

For example:

s:24:"https://old.example.com";

Replacing that URL with a different-length value using an ordinary SQL string replacement can leave the serialized structure inconsistent.

This is why Why Serialized Data Breaks Naive WordPress Migrations is an important companion guide for domain-changing migrations.

Step 26: Use serialization-aware URL replacement

WP-CLI provides:

wp search-replace

The official WP-CLI search-replace documentation states that the command handles PHP serialized data.

Start with a dry run:

wp search-replace \
'https://old.example.com' \
'https://new.example.com' \
--all-tables-with-prefix \
--dry-run

Review the result before removing --dry-run.

Step 27: Do not replace URLs you do not understand

A global replacement can affect more than ordinary content.

The old domain may appear in:

• API endpoints;
• license data;
• external service configuration;
• historical logs;
• serialized plugin settings;
• custom tables;
• email templates.

Understand where replacements occur before writing them.

Step 28: Check hard-coded URLs in files

Database search and replace cannot fix a URL hard-coded in:

• theme PHP;
• plugin PHP;
• JavaScript;
• CSS;
• configuration files;
• deployment scripts.

Search the codebase for the old hostname separately.

Step 29: Plan redirects before launch

If public URLs change, create an old-to-new URL map before switching traffic.

For example:

OLD URL                     NEW URL

/old-service/               /services/
/blog/old-post/             /guides/old-post/
/old-product/               /products/new-product/

TheOneWP’s Redirect Manager can manage redirect rules inside WordPress when URL transitions need to be preserved.

Step 30: Avoid redirecting every old URL to the homepage

A redirect should normally lead to the closest meaningful replacement.

For example:

/services/web-design-old/
↓
/services/web-design/

is useful.

This:

/anything-that-no-longer-exists/
↓
/

usually is not.

For redirect status selection, see 301 vs. 302 vs. 410: Which Redirect to Use.

Step 31: Avoid redirect chains

Do not migrate:

/old-a/
↓
/old-b/
↓
/old-c/
↓
/new/

when the old URL can point directly to the final destination:

/old-a/
↓
/new/

Redirect maps should be normalized before launch.

Step 32: Inventory DNS before changing it

Record the current DNS zone before modifying anything.

Important records may include:

• A;
• AAAA;
• CNAME;
• MX;
• TXT;
• SPF;
• DKIM;
• DMARC;
• verification records;
• service-specific records.

A website migration should not accidentally become an email migration.

Step 33: Know who controls DNS

Before launch, identify:

Domain registrar
DNS provider
Nameservers
Person with access
Required credentials
Required approval process

Do not wait until the migration window to discover that the DNS account belongs to a former supplier.

Step 34: Plan DNS TTL changes

If the migration depends on changing DNS records, review the current TTL values in advance.

Where appropriate, lowering relevant TTLs before the migration can reduce the period during which resolvers continue using older records.

Do this early enough for the previous TTL to expire before the planned switch.

Step 35: Prepare HTTPS before traffic arrives

The destination should be ready to serve the final production hostname over HTTPS.

Check:

• certificate availability;
• certificate hostname coverage;
• renewal mechanism;
• HTTP-to-HTTPS redirects;
• proxy or CDN SSL configuration;
• origin SSL configuration.

Do not treat HTTPS as a post-launch decoration.

Step 36: Check mixed content

After moving from HTTP to HTTPS or changing domains, search for old insecure resource URLs.

Examples include:

http://old.example.com/image.jpg
http://old.example.com/script.js
http://old.example.com/font.woff2

Mixed content can affect images, scripts, fonts and browser security behavior.

Step 37: Plan staging validation

Whenever possible, test the migrated site before production traffic reaches it.

A staging environment allows you to validate:

• database import;
• PHP compatibility;
• plugin behavior;
• theme rendering;
• forms;
• authentication;
• checkout;
• API integrations;
• redirects;
• URL replacement;
• caching.

WordPress Staging Site Best Practices covers the wider process of isolating and validating a non-production environment.

Step 38: Keep staging out of search results

A migration staging environment should not compete with production in search engines.

Use appropriate controls to prevent unintended public discovery and indexing while still allowing authorized testers to access the site.

Do not rely on robots.txt as though it were an access-control system. Robots.txt vs. Real Access Control explains the distinction.

Step 39: Test the site using the final hostname when possible

Some migration problems only appear when WordPress receives the real production hostname.

Before DNS changes, advanced testing can use controlled local hostname resolution so the production domain points to the destination server only for the tester.

This helps validate:

• WordPress URL handling;
• HTTPS;
• redirects;
• cookies;
• authentication;
• absolute URLs;
• canonical output.

Step 40: Plan how changing production data will be handled

Static brochure sites are relatively easy to migrate.

Dynamic sites are not.

During migration, production may continue receiving:

• orders;
• users;
• comments;
• form submissions;
• bookings;
• membership changes;
• content edits;
• inventory updates.

A database copied at 10:00 is already outdated if production receives an order at 10:01.

Step 41: Define the final synchronization strategy

For dynamic sites, decide how the final production state reaches the destination.

Possible strategies include:

Maintenance window
↓
Stop writes
↓
Final database export
↓
Final import
↓
Switch traffic

or a more advanced synchronization process where supported by the infrastructure.

The correct strategy depends on how much live data the site generates and how much downtime is acceptable.

Step 42: Plan maintenance mode carefully

A migration window may require temporarily preventing visitors from changing data.

TheOneWP’s Maintenance Mode can support controlled temporary unavailability during maintenance work.

For the broader implementation strategy, see WordPress Maintenance Mode Best Practices.

Step 43: Do not leave ecommerce writes open during a final database copy

Consider:

12:00
database exported

12:03
customer places order #1051

12:05
old database imported on new server

12:10
DNS switched

Order #1051 exists only on the old production database.

The migration may look successful while real business data has been lost.

For ecommerce and other transactional systems, write control and final synchronization are central migration requirements.

Step 44: Export the final database

WP-CLI includes database commands for exporting and importing WordPress databases.

For example:

wp db export migration.sql

The official WP-CLI database command documentation covers database export, import, search, optimization and related operations.

Use a filename and storage location that make it clear which environment and timestamp the export represents.

Step 45: Transfer files

Transfer the required WordPress files to the destination.

Depending on the migration, that may include:

wp-content/
wp-config.php
.htaccess
custom configuration
custom server files

WordPress Core can often be deployed independently rather than treated as irreplaceable site data, but the exact process depends on your deployment model.

Step 46: Verify file completeness

Do not assume a completed transfer means every file arrived correctly.

Check:

• file counts where practical;
• archive integrity;
• uploads directories;
• large media files;
• custom plugins;
• child themes;
• must-use plugins;
• hidden configuration files.

Step 47: Import the database

After preparing the destination database, import the final source database.

For WP-CLI environments this may be:

wp db import migration.sql

After import, verify that WordPress can read the database before continuing with URL replacement or launch operations.

Step 48: Update database credentials

If the destination uses different credentials, update the environment configuration accordingly.

Verify:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST

Do not leave obsolete production credentials in unnecessary copies of configuration files or migration archives.

Step 49: Perform URL replacement if required

If the hostname or path changes, perform the planned serialization-aware replacement.

A typical workflow is:

wp search-replace \
'https://old.example.com' \
'https://new.example.com' \
--all-tables-with-prefix \
--dry-run

Review the result.

Then perform the actual operation only when the scope is correct.

How to Migrate WordPress URLs Safely covers this part of the process in greater depth.

Step 50: Search for remaining source URLs

After replacement, search for the old hostname again.

Possible remaining references can exist in:

• plugin tables;
• hard-coded theme files;
• CSS;
• JavaScript;
• external integrations;
• logs;
• configuration files.

Not every remaining occurrence should necessarily be replaced, but every unexpected occurrence should be understood.

Step 51: Check permalinks

After migration, verify that normal WordPress routes work correctly.

Test:

• homepage;
• posts;
• pages;
• categories;
• tags;
• custom post types;
• taxonomy archives;
• pagination;
• feeds.

If the web server changed, rewrite configuration may also need adjustment.

Step 52: Check .htaccess or Nginx configuration

Apache and Nginx do not use the same rewrite configuration.

A migration from Apache to Nginx therefore requires more than copying .htaccess, because Nginx does not use that file for request routing.

Review:

• WordPress rewrites;
• redirects;
• security rules;
• cache rules;
• compression;
• static-file behavior;
• custom application routes.

Step 53: Check media files

Open representative media from different periods of the site’s history.

Test:

• recent uploads;
• old uploads;
• images;
• PDF files;
• video files where locally hosted;
• generated image sizes.

A homepage loading correctly does not prove that five years of uploads were transferred successfully.

Step 54: Check image URLs

Inspect image markup and CSS backgrounds for references to:

• the old hostname;
• staging;
• localhost;
• old CDN domains;
• obsolete filesystem-derived paths.

Step 55: Check menus and internal links

Crawl or manually inspect important internal navigation.

Check:

• header menus;
• footer menus;
• buttons;
• breadcrumbs;
• related-content links;
• sidebar links;
• hard-coded template links.

If the domain changed, internal links should resolve directly to the new destination rather than unnecessarily passing through redirects.

Step 56: Check canonical URLs

Canonical tags should reference the intended production URLs after migration.

A migrated page should not continue publishing:

<link rel="canonical"
href="https://staging.example.com/page/">

when the real page is:

https://example.com/page/

For the underlying concept, see WordPress Canonical URLs, Explained.

Step 57: Check the XML sitemap

After a domain-changing migration, inspect the sitemap and confirm that it contains production URLs.

TheOneWP’s XML Sitemap can generate sitemap output for the site’s indexable content.

For the broader role of sitemap files, see What Is an XML Sitemap and Why Does It Matter?.

Step 58: Check robots.txt

A staging environment may deliberately discourage crawling.

Production should not accidentally inherit staging-specific crawling restrictions.

Inspect the final robots.txt behavior after launch.

Again, crawling rules are not security controls. Robots.txt vs. Real Access Control explains why the two should not be confused.

Step 59: Check WordPress search-engine visibility settings

A common migration mistake is moving staging to production while retaining settings intended to discourage indexing.

Review the production site’s search-engine visibility configuration as part of the launch checklist.

Step 60: Test forms

Submit every important form.

Do not merely check that the form renders.

Verify:

Form displays
↓
Submission succeeds
↓
Data is stored correctly
↓
Notification is sent
↓
Recipient receives it
↓
Redirect or confirmation works

Step 61: Test outgoing email

Server migrations frequently change the environment responsible for sending email.

Test:

• password reset emails;
• contact forms;
• order emails;
• administrative notifications;
• custom workflow emails.

Do not assume successful PHP execution means successful email delivery.

For common delivery problems, see Why WordPress Emails Go to Spam.

Step 62: Test user authentication

Test:

• login;
• logout;
• password reset;
• administrator access;
• editor access;
• custom roles;
• two-factor authentication if enabled.

Incorrect URL, cookie, HTTPS or proxy configuration can produce login loops after migration.

The official WordPress login troubleshooting documentation specifically identifies incorrect WP_HOME, WP_SITEURL, mixed HTTP/HTTPS configuration and proxy settings as possible causes of redirect problems.

Step 63: Test ecommerce

For ecommerce sites, test the complete transaction lifecycle.

That may include:

• product pages;
• cart;
• checkout;
• payment;
• webhooks;
• order creation;
• transactional email;
• inventory changes;
• customer accounts.

Use appropriate test or sandbox transactions when available.

Step 64: Review payment and API callbacks

External systems may call URLs on the WordPress site.

Examples include:

Payment webhook
CRM callback
OAuth callback
Form integration
Shipping API
Automation webhook

If the domain changes, those remote services may also need their callback URLs updated.

Step 65: Review API keys and environment-specific credentials

Staging and production should not automatically share every secret.

Check:

• payment keys;
• CRM credentials;
• SMTP credentials;
• analytics identifiers;
• storage credentials;
• webhook secrets;
• third-party API keys.

A migration should preserve the credentials appropriate for the destination environment, not blindly copy whichever credentials happened to exist at the source.

Step 66: Check WordPress cron

Review scheduled tasks after migration.

They may control:

• scheduled publishing;
• email queues;
• ecommerce actions;
• cleanup tasks;
• external synchronization;
• backup schedules;
• plugin maintenance.

If the site uses a real server cron instead of normal traffic-triggered WP-Cron, recreate that configuration on the destination.

Step 67: Check object caching

If the source uses Redis or another persistent object cache, verify the destination configuration.

Check:

• host;
• port;
• authentication;
• database or namespace;
• persistent connection behavior;
• cache prefix.

Do not accidentally connect staging and production to the same cache namespace.

Step 68: Clear environment-specific caches

After migration, cached data may still contain assumptions from the source environment.

Depending on the architecture, clear or regenerate:

• page cache;
• object cache;
• CDN cache;
• application cache;
• generated CSS;
• page-builder cache;
• temporary cached data.

Cache clearing should be deliberate rather than ceremonial. The important question is whether cached state can contain source-environment URLs, paths or configuration.

Step 69: Review transients

WordPress transients are temporary cached values and may contain environment-specific information.

Examples include:

• remote API responses;
• temporary URLs;
• external resource data;
• cached configuration.

They can often regenerate, but do not blindly delete data unless you understand how the site uses it.

Step 70: Check CDN configuration

If a CDN is involved, verify:

• origin hostname;
• origin IP;
• SSL mode;
• cache behavior;
• purge behavior;
• redirect behavior;
• security rules;
• custom headers.

A DNS change can point visitors to the new server while the CDN continues requesting content from the old origin.

Step 71: Check security rules

Review infrastructure-specific security controls such as:

• firewalls;
• WAF rules;
• IP allowlists;
• rate limits;
• basic authentication;
• server access restrictions;
• bot controls.

A perfectly migrated WordPress application is still unavailable if the new firewall blocks the traffic it needs.

Step 72: Check file paths

Moving servers can change absolute filesystem paths.

For example:

/home/olduser/public_html/

↓

/var/www/example/current/

Search custom configuration and code for old absolute paths where relevant.

Step 73: Check upload paths

Most WordPress installations use standard upload handling, but older or customized sites may contain custom upload-path configuration.

Verify that media uploads work after migration by uploading a new file and confirming that:

• the file is written;
• metadata is generated;
• image sizes are created;
• the public URL works.

Step 74: Check temporary directories

WordPress and plugins may need writable temporary storage for:

• updates;
• archives;
• imports;
• exports;
• image processing;
• backups.

A migration can expose missing or incorrectly permissioned temporary directories even when ordinary page rendering works.

Step 75: Check image processing

Upload a new image and verify thumbnail generation.

The destination PHP environment should provide the image-processing capabilities expected by WordPress and the site’s plugins.

Step 76: Test plugin and theme updates

After migration, verify that WordPress can perform normal maintenance operations.

Check whether:

• plugin updates can download;
• theme updates can download;
• filesystem writes succeed;
• temporary files can be created;
• update endpoints are reachable.

Step 77: Check licenses

Some commercial plugins and themes bind licenses to:

• domain;
• hostname;
• installation URL;
• activation count.

A domain-changing migration may therefore require license reactivation or environment changes.

Step 78: Check external storage

If media or backups use external object storage, verify:

• credentials;
• bucket;
• region;
• endpoint;
• public URL;
• permissions;
• CDN mapping.

Step 79: Prepare monitoring before launch

Do not begin monitoring after somebody reports the first error.

Before switching traffic, prepare checks for:

• HTTP availability;
• PHP errors;
• server errors;
• database errors;
• response time;
• checkout failures;
• form failures;
• cron failures;
• email failures.

Step 80: Record the source server IP

Keep the source server’s details available during the migration window.

After DNS changes, being able to access both:

old environment
and
new environment

can be extremely useful for comparing behavior and recovering missing data.

Step 81: Perform the final pre-launch backup

Immediately before the final migration operation, create the recovery point defined in your plan.

TheOneWP’s Backup Manager can provide complete, database-only or files-only backup workflows depending on what needs to be protected.

For most full-site migrations, a complete pre-migration recovery point is the safest baseline.

Step 82: Freeze production writes when required

For sites where live data matters, stop or control writes before creating the final database snapshot.

That may involve:

• maintenance mode;
• disabling checkout;
• disabling forms;
• blocking content editing;
• pausing integrations;
• pausing queues.

Step 83: Record the migration start time

Record exactly when the final migration begins.

This provides a reference point when reviewing:

• orders;
• logs;
• form submissions;
• database changes;
• DNS changes;
• monitoring events.

Step 84: Perform the final synchronization

Transfer the final files and database changes according to the migration plan.

A typical controlled sequence might be:

Enable maintenance
↓
Stop changing data
↓
Create final database export
↓
Synchronize changed files
↓
Import final database
↓
Run required URL replacement
↓
Clear caches
↓
Validate destination
↓
Switch traffic

Step 85: Test before DNS switch

Where the infrastructure allows it, perform final validation against the destination before public DNS changes.

At minimum test:

• homepage;
• representative pages;
• WordPress admin;
• login;
• forms;
• media;
• database connectivity;
• critical integrations.

Step 86: Switch DNS or routing

Once the destination is validated, switch the mechanism that sends production traffic to it.

This may be:

• DNS A/AAAA record;
• CNAME;
• load balancer;
• reverse proxy;
• CDN origin;
• hosting platform routing.

Record the exact time and values changed.

Step 87: Do not immediately destroy the source environment

Keep the old environment available for the rollback period where practical.

Immediately deleting the source server removes one of the most useful recovery options precisely when the migration has the least production history.

Step 88: Verify DNS resolution

After the switch, confirm that the production hostname resolves to the intended destination.

Check both:

• IPv4 where used;
• IPv6 where used.

Also verify CDN or proxy resolution when those layers sit in front of the origin.

Step 89: Verify HTTPS publicly

Test the production hostname from a normal external connection.

Confirm:

• certificate validity;
• correct hostname;
• full certificate chain;
• HTTP-to-HTTPS redirect;
• no redirect loop.

Step 90: Test critical URLs

Create a concise launch URL set before migration.

For example:

/
 /about/
 /contact/
 /blog/
 /important-post/
 /product/
 /cart/
 /checkout/
 /wp-login.php

Test them immediately after traffic switches.

Step 91: Test HTTP status codes

Do not check only what pages look like.

Verify that responses communicate the correct status:

normal page → 200
permanent move → 301
temporary move → 302
missing page → 404
temporary maintenance → 503

For a deeper explanation, see HTTP Status Codes for WordPress Sites, Explained.

Step 92: Test redirects

Test representative URLs from the migration redirect map.

Verify:

• correct destination;
• correct status code;
• no loops;
• no unnecessary chains;
• query-string behavior where relevant.

TheOneWP’s Redirect Manager can centralize WordPress-managed redirect rules and make post-launch redirect maintenance easier.

Step 93: Test 404 behavior

Request a URL that definitely does not exist.

It should not:

• return a fake 200 response;
• redirect blindly to the homepage;
• produce a server error;
• expose staging infrastructure.

Step 94: Crawl the migrated site

A post-migration crawl can identify:

• broken internal links;
• old-domain references;
• redirect chains;
• 404 responses;
• incorrect canonical URLs;
• missing images;
• mixed content;
• unexpected status codes.

Compare the results with a pre-migration crawl when available.

Step 95: Check the database for old environment references

Search for:

old.example.com
staging.example.com
dev.example.com
localhost
127.0.0.1

Investigate unexpected occurrences.

TheOneWP’s Database Manager can help inspect database tables and stored records when post-migration verification requires deeper investigation.

Step 96: Check error logs

Immediately after launch, inspect:

• PHP error logs;
• web-server error logs;
• WordPress debug logs where appropriately enabled;
• application logs;
• plugin-specific logs.

A page can appear correct while background operations are generating warnings or failures.

Step 97: Test WordPress admin operations

Log in and perform ordinary administrative work.

Test:

• editing a post;
• saving a page;
• uploading media;
• creating a draft;
• using custom post types;
• plugin administration;
• user administration where appropriate.

Step 98: Test scheduled tasks after traffic switches

Some failures appear only when the next scheduled job executes.

Monitor:

• scheduled posts;
• queues;
• cleanup jobs;
• API synchronization;
• backup jobs;
• email jobs.

Step 99: Check production email again

Send real test messages from the production environment after the final DNS and server switch.

This confirms that the final production routing, SMTP configuration and DNS environment work together.

Step 100: Monitor the site after migration

A migration is not complete when DNS changes.

Continue monitoring for:

• HTTP errors;
• PHP errors;
• slow responses;
• failed background jobs;
• failed forms;
• failed payments;
• broken redirects;
• missing assets;
• email problems.

Keep the rollback window open

Do not destroy the source environment immediately after the first successful homepage request.

A sensible sequence is:

Launch
↓
Immediate validation
↓
Critical workflow validation
↓
Monitoring period
↓
Confirm data integrity
↓
Confirm integrations
↓
Close rollback window
↓
Decommission source

When should the old server be removed?

Only after you are satisfied that:

• production traffic reaches the new environment;
• DNS has stabilized;
• critical workflows work;
• all required data exists;
• forms work;
• email works;
• payments work where applicable;
• scheduled tasks work;
• redirects work;
• backups run on the new environment;
• rollback is no longer reasonably required.

Take a fresh backup after migration

Once the destination is confirmed as the new production environment, create a new backup there.

This establishes a clean recovery point for the migrated infrastructure.

TheOneWP’s Backup Manager can then continue providing complete, database-only or files-only recovery points according to the site’s backup strategy.

Migration checklist: planning phase

• Define the exact source and destination.
• Determine whether the domain changes.
• Determine whether the URL structure changes.
• Record WordPress version.
• Record PHP version.
• Record database engine and version.
• Inventory plugins.
• Inventory themes.
• Inventory must-use plugins.
• Inventory custom code.
• Inventory external integrations.
• Measure database size.
• Measure filesystem size.
• Review DNS.
• Review HTTPS.
• Review email architecture.
• Review caching architecture.
• Define maintenance requirements.
• Define final synchronization strategy.
• Define rollback criteria.

Migration checklist: backup phase

• Create a complete backup.
• Verify the database export.
• Verify files.
• Verify uploads.
• Verify custom code.
• Store the backup separately.
• Document restoration steps.
• Confirm the source environment remains recoverable.

Migration checklist: destination preparation

• Prepare web server.
• Prepare PHP.
• Install required PHP extensions.
• Prepare database.
• Prepare filesystem.
• Configure permissions.
• Prepare SSL.
• Prepare object caching.
• Prepare page caching.
• Prepare cron.
• Prepare email.
• Prepare monitoring.
• Prepare CDN or proxy configuration.

Migration checklist: transfer

• Enable maintenance or write controls when required.
• Record migration start time.
• Create final database snapshot.
• Synchronize files.
• Import database.
• Update database credentials.
• Update environment-specific configuration.
• Perform serialization-aware URL replacement when required.
• Search for old environment URLs.
• Clear relevant caches.
• Validate the destination before switching traffic.

Migration checklist: launch

• Switch DNS or routing.
• Verify DNS resolution.
• Verify HTTPS.
• Verify homepage.
• Verify representative pages.
• Verify WordPress admin.
• Verify login.
• Verify media.
• Verify forms.
• Verify email.
• Verify ecommerce where applicable.
• Verify external APIs.
• Verify webhooks.
• Verify redirects.
• Verify 404 behavior.
• Verify canonical URLs.
• Verify XML sitemap.
• Verify robots.txt.
• Verify search-engine visibility.

Migration checklist: post-launch

• Crawl the production site.
• Search for old URLs.
• Check error logs.
• Check scheduled tasks.
• Check forms again.
• Check email again.
• Check payments.
• Check background queues.
• Monitor server performance.
• Monitor application errors.
• Keep the source available during the rollback window.
• Create a fresh destination backup.
• Document the completed migration.
• Decommission the source only after validation.

Common WordPress migration mistake: treating the site as files only

A WordPress installation is not simply:

public_html/

It is a relationship between:

Files
+
Database
+
Server configuration
+
DNS
+
External services
+
Runtime environment

Moving only one layer can produce a site that appears partially functional while important systems remain connected to the old environment.

Common WordPress migration mistake: changing too many variables

A migration is already a significant infrastructure event.

Combining it with:

new host
new PHP
new WordPress
new theme
plugin cleanup
database cleanup
new CDN
new domain

makes failures much harder to isolate.

Where possible, migrate first and modernize afterward.

Common WordPress migration mistake: forgetting serialized data

WordPress and its plugins frequently store structured data that cannot safely be modified using naive SQL string replacement.

Use WordPress-aware tools and review Why Serialized Data Breaks Naive WordPress Migrations before changing stored URLs.

Common WordPress migration mistake: forgetting production writes

For dynamic sites, the migration plan must account for data created during the transfer.

The problem is not:

Can we copy the database?

It is:

Can we copy the database
without losing anything created
after the copy started?

That distinction is critical for ecommerce, membership, booking and high-activity editorial sites.

Common WordPress migration mistake: having a backup but no rollback plan

A backup answers:

Do we have the old data?

A rollback plan answers:

How do we restore service
using that data?

You need both.

Common WordPress migration mistake: forgetting DNS services unrelated to the website

If nameservers are changed rather than only the website record, the migration can affect services unrelated to WordPress.

Preserve required:

• MX records;
• SPF records;
• DKIM records;
• DMARC records;
• verification records;
• third-party service records.

Common WordPress migration mistake: declaring success too early

This:

Homepage loads
↓
Migration complete

is not a migration test.

A meaningful validation process includes:

Frontend
+
Backend
+
Authentication
+
Content
+
Media
+
Forms
+
Email
+
Scheduled tasks
+
External integrations
+
SEO signals
+
Monitoring

How TheOneWP can support a WordPress migration

Several TheOneWP modules can support different parts of a migration workflow.

Backup Manager

Backup Manager provides the recovery layer that should exist before migration work begins.

It can support:

• complete backups;
• database-only backups;
• files-only backups;
• recovery workflows;
• migration preparation.

Database Manager

Database Manager provides visibility into WordPress database tables, structures and records.

That can help identify:

• custom tables;
• unexpected data;
• large tables;
• migration-sensitive records;
• environment-specific values.

Redirect Manager

Redirect Manager can manage URL transitions when pages or paths change during migration.

This is particularly useful when a migration also includes:

• domain restructuring;
• permalink changes;
• content consolidation;
• old-to-new URL mapping.

Maintenance Mode

Maintenance Mode can support a controlled migration window when public access or writes need to be temporarily restricted.

XML Sitemap

XML Sitemap can help ensure the migrated production site exposes the intended indexable URLs after launch.

A practical WordPress migration sequence

1. Define migration scope

2. Audit source site

3. Inventory:
   files
   database
   plugins
   themes
   integrations
   DNS
   email
   caching

4. Prepare destination

5. Create and verify backup

6. Define rollback

7. Test migration on staging

8. Prepare URL replacement

9. Prepare redirects

10. Prepare DNS switch

11. Prepare HTTPS

12. Prepare monitoring

13. Control production writes

14. Create final database snapshot

15. Synchronize files

16. Import database

17. Update configuration

18. Replace URLs safely

19. Clear relevant caches

20. Validate destination

21. Switch traffic

22. Test critical workflows

23. Crawl production

24. Monitor errors

25. Keep rollback available

26. Create new production backup

27. Decommission old infrastructure

Related guides

• Preparing a WordPress Database for Migration
• How to Migrate WordPress URLs Safely
• Why Serialized Data Breaks Naive WordPress Migrations
• WordPress Staging Site Best Practices
• WordPress Maintenance Mode Best Practices

Final recommendation

A successful WordPress migration starts before the first file is copied. Define exactly what is changing, audit the source environment, prepare the destination and create a verified recovery point before modifying production.

For the database layer, use Preparing a WordPress Database for Migration to identify custom tables, unnecessary data and environment-specific values before export. TheOneWP’s Database Manager can provide additional visibility into the tables and records being moved.

Always create a recoverable pre-migration copy. TheOneWP’s Backup Manager can provide complete, database-only and files-only backup workflows, but the important operational requirement is that the recovery point exists outside the infrastructure being changed and that the restoration process is understood.

If the domain or path changes, do not treat URL migration as ordinary text replacement. WordPress databases can contain serialized values, plugin-specific tables and environment-specific configuration. Follow How to Migrate WordPress URLs Safely and understand Why Serialized Data Breaks Naive WordPress Migrations before modifying stored URLs.

Plan redirects before launch rather than discovering broken URLs afterward. TheOneWP’s Redirect Manager can manage old-to-new URL mappings where the migration changes public paths, while XML Sitemap can help expose the intended production URLs after the new environment becomes canonical.

For sites that continue receiving orders, registrations, form submissions or editorial changes, define how changing production data will be synchronized. A migration that transfers every file perfectly but loses the final thirty minutes of orders is not successful.

Finally, keep the source environment and rollback procedure available until the destination has been validated under real production traffic. Test the frontend, backend, authentication, media, forms, email, scheduled tasks, integrations, redirects and SEO signals. Then create a fresh backup of the new production environment and only afterward decommission the old infrastructure.