WordPress Migration Test Methodology

Migration Monkey's automated WordPress path is tested as a pair of source and destination agents, not only as a calculator or interface. The test exercises direct HTTP transfer behavior, database import, WordPress URL replacement, destination configuration, resume handling, and error states that must stop a job instead of reporting a false success.

Current result: 27 of 27 integration checks passed on July 16, 2026 against PHP 8.3 and MariaDB using a WordPress 4.9.26 fixture.

Current Test Fixture

• WordPress version: 4.9.26, selected to exercise an older supported WordPress generation.
• Transfer fixture: 5 files totaling about 2.8 MB, sent in 10 transport chunks.
• Database fixture: 5 WordPress tables and 10 rows.
• URL rewrite fixture: 15 replacements across normal strings, serialized values, escaped JSON, and URL-encoded values.
• Runtime: live cPanel PHP 8.3 source/destination execution with MariaDB destination import.

What The Harness Verifies

• Source application markers match the selected WordPress profile.
• Destination database credentials succeed before files or SQL are committed.
• Files are staged, checksummed, committed atomically, and retain mode and modification time.
• Large files use 512 KiB chunks so transfers fit strict proxy request-body limits.
• A resumed job skips files that already match and retransmits a changed configuration file.
• Only tables matching the exact detected WordPress prefix are imported.
• Numeric and binary database values preserve their types.
• Generated columns are excluded from direct writes and recomputed by MariaDB.
• The copied wp-config.php is rewritten atomically with destination database credentials.
• Old HTTP and HTTPS URLs, protocol-relative values, escaped JSON, URL-encoded values, and PHP-serialized values are replaced without corrupting serialization lengths.
• Logs report changed values, occurrences, serialized values, table progress, warnings, and completion state.

Fail-Closed Cases

The integration run also proves that known unsafe or unsupported cases stop with a useful error. Bad destination credentials, a destination with no database configuration, application-profile mismatch, late multi-statement SQL errors, prefixed views, triggers, symbolic links, and legacy custom Serializable objects do not get reported as successful migrations.

What This Result Does Not Claim

The current fixture proves the transfer and rewrite mechanics across the cases above. It is not a claim that every plugin, theme, host, 3 GB file set, 500 MB database, firewall, or custom WordPress table has been reproduced in one laboratory job. A production source analysis and destination verification are still required.

Automated database replacement is currently limited to detected WordPress jobs. Non-WordPress application profiles can use file transfer and planning workflows, but they remain in a needs-attention state until their app-specific database and runtime completion path is verified.

How To Verify Your Own Migration

1. Run Analyze source and confirm the detected version, root, files, database bytes, and table prefix.
2. Prepare a separate destination and test its database credentials before transfer.
3. Use a temporary domain, explicit destination agent URL, or hosts-file route before public DNS changes.
4. After transfer, inspect checksum, skipped-file, database table, and URL rewrite counters.
5. Verify admin login, media, forms, scheduled tasks, plugins, redirects, HTTPS, and rollback before cutover.

Related Technical Guides

Continue with the server-to-server architecture guide, WordPress URL replacement guide, agent troubleshooting guide, and post-migration checklist.