Server-To-Server Website Migration

A direct server-to-server migration uses the source and destination systems to exchange website files and database data. Migration Monkey coordinates authorization, app detection, the estimate, one-time agent handshakes, progress, warnings, checksums, and operator logs without using the control plane as a permanent archive for customer payloads.

How The Direct Route Works

  1. The customer creates a migration job and confirms ownership or authorization for the data.
  2. The source agent inspects the selected install path, detects the application and version, and measures files and databases.
  3. The destination agent verifies disk space, runtime, permissions, database access, and the target path.
  4. The control plane issues a short-lived job handshake so the two endpoints can authenticate for that migration.
  5. The source streams resumable chunks to the destination, where hashes and restore results are checked.
  6. The destination runs application-aware restore and verification steps before DNS cutover.

Supported Access Patterns

A source or destination may use a WordPress agent installed through wp-admin, a control-panel account, SSH, SFTP, database credentials, or a provider-specific API/export route. A fresh WordPress destination is often the simplest receiver, but the final domain does not need to point there yet. The destination can be reached through a temporary hostname, server IP, preview route, or a hosts-file override.

Credentials And Saved Servers

Users can save endpoint labels, hostnames, usernames, ports, application paths, and preferred methods for repeat work. Passwords, private keys, database passwords, and OAuth tokens belong to a single migration job. They should be encrypted for the active handshake, excluded from logs, and removed when the job retention window ends.

Large File Trees And Databases

One giant ZIP file is fragile on shared hosting and strict WAFs. A resumable route splits work into bounded chunks, records completed ranges, retries failed pieces, and verifies the destination checksum. Databases should be exported in a format the destination engine can import, with warnings for unsupported collations, definer clauses, triggers, routines, packet limits, or tables that need repair.

Domain Changes And WordPress Search Replace

For a new domain or temporary-domain test, WordPress needs serialized-safe URL replacement rather than a plain SQL string replacement. Other platforms may require configuration files, environment variables, base URL settings, cache rebuilds, redirect maps, or application-specific CLI commands. The migration route should make those changes explicit and reversible.

When Direct Transfer Is Blocked

Cloudflare, Sucuri, managed-host restrictions, PHP execution limits, blocked plugins, outbound firewall rules, or origin locking can prevent the agents from reaching each other. Use scoped WAF allowances, a signed temporary route, control-panel transfer tools, provider exports, or an assisted migration path. Do not disable an entire WAF longer than the migration window.

Proof Of A Finished Migration

A completed transfer should show more than 100 percent progress. Review file and database checks, skipped-item warnings, admin login, frontend routes, media, forms, cron, queues, redirects, SSL, DNS, CDN behavior, and application logs. Start with the website migration checklist and finish with the post-migration checklist.