WordPress Database Migration QA: URLs, Serialization, Users, Media.

WordPress database migration QA proves that a site can move without corrupting structured settings, losing users, pointing media at the wrong host, omitting plugin data, or trapping the team after cutover. The release gate compares source and target manifests, performs serialization-aware transformations, validates behavior, and keeps a tested rollback path until the new site is accepted.

Work on approved copies in an isolated target environment. Keep production database dumps, credentials, password hashes, customer records, form entries, order data, and private uploads out of tickets and shared logs. Use encrypted storage, least-privilege access, safe counts, hashes, and synthetic test records for evidence.

Define Migration Scope

State whether the move changes server, database host, domain, protocol, path, table prefix, WordPress version, PHP version, multisite topology, or only one component. List files, database tables, uploads, configuration, secrets, scheduled jobs, caches, search indexes, and external integrations that must move or be rebuilt.

Name the source of truth and the allowed write window. A database-only copy is not a complete site migration when uploads or generated files remain elsewhere. Define success, acceptable downtime, recovery time, maximum data loss, and who can approve cutover or rollback.

Capture Source And Target Manifests

Record WordPress core, PHP, database engine, active theme, plugins, must-use plugins, drop-ins, table prefix, table list, row counts, database size, upload counts, home URL, site URL, permalink structure, cron configuration, and important integration endpoints. Capture the target equivalents before importing.

Use commands and queries that do not expose secrets or full content. Hash deployment packages and backup files. A manifest makes drift visible: an extra target plugin, missing custom table, different collation, or mismatched core version can explain failures that otherwise look like random migration defects.

Create Restorable Backups

Back up the database and all required files before any transformation. The WordPress migration handbook explicitly calls for database and file backups. Store copies outside both source and target failure domains, encrypt them, restrict access, and record creation time, source version, size, and checksum.

A backup is not proven until it restores into an isolated environment. Test import, WordPress bootstrap, administrator access through an approved test account, representative pages, media, and plugin data. Document the exact restore command and expected duration rather than assuming an archive is usable.

Prepare An Isolated Target

Build the target with production-like web server, PHP extensions, database settings, storage permissions, rewrite rules, object cache, and scheduled-task behavior. Keep it inaccessible to search engines and unauthorized users through network or authentication controls, not only a robots directive.

Use a controlled hostname and HTTPS certificate. Prevent the target from sending real email, charging payments, calling live webhooks, modifying external stock, or running duplicate scheduled jobs. Replace these integrations with approved sandboxes or sinks while retaining observable behavior.

Control Database Credentials

Create a target database and least-privilege application user, then configure wp-config.php through the deployment’s secret mechanism. Never copy source database credentials into the target by habit or embed them in a migration script, archive, command history, or issue.

Verify the target connects only to the intended database. Check host, name, user, prefix, charset, collation, SSL requirements, and read/write privileges. A staging site accidentally connected to production can pass visual QA while corrupting live data.

Inventory Tables And Prefixes

List WordPress core tables plus plugin, theme, commerce, analytics, form, membership, queue, and custom tables. WP-CLI defaults may focus on tables registered to the current WordPress installation, so choose network, prefix, or explicit table scope according to the site architecture.

If the table prefix changes, inspect user capability and user-level metadata keys that embed the old prefix. WordPress documentation warns that usermeta entries require attention when prefixes change. Test administrator, editor, customer, and custom roles after import rather than checking only the users table.

Export At A Consistent Point

Choose a maintenance window, database snapshot, transaction-capable export, or application write freeze that produces a consistent dataset. Record the start and end time and any tables that continue changing. Include triggers, routines, views, or events only when the application uses and permits them.

Use WP-CLI database export or an approved database-native tool with explicit options. Validate exit status, file size, checksum, and a safe table summary. Do not treat a partially written dump as success merely because a file exists.

Import Without Silent Loss

Create or clean the intended target schema through an approved process, then import the exact verified dump. Capture warnings and errors, database mode, character set, collation conversions, packet limits, timeouts, and duplicate-key behavior. Stop on truncation or skipped statements.

After import, compare table counts, row counts for critical tables, schema definitions, selected object counts, and safe aggregates. WP-CLI database commands can support checks, imports, tables, and sizes. Differences need an explanation tied to approved exclusions or transformations.

Replace URLs Safely

When domain, protocol, or path changes, inventory the exact old and new values, including escaped forms and CDN hosts. Use serialization-aware tooling. WP-CLI search-replace is designed to handle PHP serialized data and offers a dry-run report before changes are saved.

Run a narrowly scoped dry run, review affected tables and columns, then execute against a fresh restorable copy. Avoid unrestricted SQL REPLACE across arbitrary text because changing string length inside serialized values can corrupt them. Preserve primary keys and consider whether GUID values should remain unchanged under the site’s migration policy.

Verify Serialized Data

Inspect representative widget settings, theme options, block data, navigation configuration, plugin settings, customizer values, page-builder structures, scheduled events, and object arrays after replacement. A site can render its homepage while a rarely used serialized option remains broken.

Search the target database for the old origin before and after transformation, classify every remaining match, and review false positives such as historical content or audit records. Test deserialization through WordPress behavior and logs, not by assuming a successful command report proves every consumer can read its values.

Protect Users And Capabilities

Compare user counts, logins, email-domain summaries where permitted, role assignments, capability metadata, application-password records, sessions, and custom membership links. Never expose password hashes in evidence. Use approved test accounts for authentication checks.

Verify administrator access, least-privilege roles, customer ownership, author attribution, and multisite membership. If the migration creates a temporary administrator, remove or disable it before release. Do not reset real passwords merely to simplify testing.

Reconcile Media And Files

Copy uploads and other required files with path, count, size, and checksum evidence. Compare database attachment records with physical objects. Test originals, generated sizes, modern formats, PDFs, private downloads, featured images, responsive srcset output, and media attached through plugin-specific storage.

Search rendered pages and database references for the old host, local filesystem paths, staging domains, or inaccessible object-store URLs. Regenerate derived image sizes only when required and documented. Do not delete source media until retention and rollback windows close.

Audit Plugin And Custom Tables

Identify each plugin’s owned tables, options, cron events, queues, uploads, and external state. Verify versions support the target PHP and database environment before cutover. Test high-impact workflows such as forms, commerce, memberships, redirects, SEO metadata, and security controls.

Treat unknown tables as evidence to investigate, not clutter to discard. Some plugins create tables without the standard prefix or outside a basic export scope. Compare schemas and representative records, and confirm deactivated but business-critical plugin data is intentionally retained or retired.

Rebuild Derived State

Purge page, object, opcode, CDN, and application caches after import according to ownership. Rebuild rewrite rules, search indexes, generated CSS, image derivatives, sitemaps, queue indexes, and other derived artifacts that should not be copied blindly.

Separate authoritative data from rebuildable state in the runbook. Observe rebuild time, errors, resource use, and completion counts. The measured WordPress audit helps distinguish migration correctness from performance regressions.

Test The Complete Site

Run public and authenticated smoke tests across homepage, key templates, posts, pages, search, archives, menus, forms, media, login, roles, APIs, feeds, sitemaps, robots, redirects, scheduled tasks, email sinks, and critical plugin workflows. Check browser, server, PHP, and database logs.

Compare status codes, canonicals, structured data, internal links, asset hosts, cookies, and response headers. Use the broader WordPress update safety checklist to preserve backup, isolated testing, and verification discipline without conflating an update with a migration.

Plan Cutover And Write Freeze

Define DNS or load-balancer changes, TTL preparation, maintenance mode, final delta capture, target import, cache purge, job ownership, health checks, communication, and acceptance checkpoints. Freeze or queue writes so orders, forms, comments, uploads, and profile changes cannot diverge across sites.

Measure propagation and keep the source available in a controlled read-only state when architecture permits. Verify traffic reaches the intended target, certificates and redirects are correct, background jobs run once, and monitoring alerts on errors, latency, queue growth, and missing business events.

Prove Rollback Before Release

Define rollback triggers, decision owner, latest safe decision time, source reactivation, DNS or routing reversal, database restoration, write reconciliation, cache clearing, and communication. Test the mechanism before the cutover window, including credentials and access needed under pressure.

Rollback becomes complex after the target accepts new writes. Decide whether those writes can be replayed, merged, exported, or must be prevented until acceptance. Block release for corrupt serialized data, missing tables, role loss, broken media, old-origin leakage, unexplained count differences, unsafe integrations, or an untested recovery path. The WordPress Development course can build the database and deployment skills behind this gate.

FAQ

Can a normal SQL replace safely change WordPress URLs?

Not reliably. Serialized values encode string lengths, so use serialization-aware tooling such as WP-CLI search-replace and review a dry run first.

Should GUID values be changed during a domain migration?

Usually they are treated as identifiers rather than display URLs; define the site’s policy and avoid changing them through a broad replacement without a specific reason.

When is rollback no longer simple?

Once the target accepts unique new writes, rollback requires reconciliation or data loss prevention rather than only switching traffic back.