How to Build a WordPress Site Migration Checklist for Agency-Scale Moves

u003cpu003eEvery migration your agency runs that starts from scratch adds hidden cost: scoping time, missed checks, inconsistent handoffs, and post-launch tickets that should never have been opened. The fix is not a better project plan. It is a runbook, a documented sequence of phases your team runs identically on every client site, regardless of size or complexity.u003c/pu003eu003cpu003eMost WordPress migration guides focus on the technical steps for a single site. This one is structured differently, because agencies running a client fleet need a framework that compounds across every move, not just a checklist that works once.u003c/pu003eu003cpu003eA migration runbook has four phases: pre-migration audit, pre-flight environment prep, cutover, and post-migration verification. Each phase ends with a signed-off checklist. The output is not just a moved site. It is a record of every decision made, every credential touched, and every test passed, which matters when a client calls three weeks later asking why their contact form stopped working.u003c/pu003eu003cpu003eStructuring migrations this way also changes how you staff them. When the steps are fixed, any trained operator on your team can run the migration, not just the person who built the original site. That is how agencies scale past their founding team without degrading quality.u003c/pu003e

u003cpu003eA pre-migration audit is the single most important phase of any WordPress site migration, because errors caught here cost nothing to fix, while the same errors caught after cutover can cost hours of recovery time and client trust.u003c/pu003eu003cpu003eBefore touching any file or database, capture and document:u003c/pu003eu003culu003eu003cliu003eu003cstrongu003eHosting environment:u003c/strongu003e PHP version, server type (Apache or Nginx), MySQL version, memory limit, max upload size, and any server-level caching layersu003c/liu003eu003cliu003eu003cstrongu003eActive plugins and themes:u003c/strongu003e version numbers, license keys, and whether each is actively maintained upstreamu003c/liu003eu003cliu003eu003cstrongu003eCustom functionality:u003c/strongu003e custom post types, taxonomies, rewrite rules, and any code in functions.php or custom pluginsu003c/liu003eu003cliu003eu003cstrongu003eMedia library:u003c/strongu003e total size, any external storage via offload plugins, and a check for broken attachmentsu003c/liu003eu003cliu003eu003cstrongu003eThird-party Connectors:u003c/strongu003e payment gateways, CRM connections, form handlers, analytics scripts, and ad tagsu003c/liu003eu003cliu003eu003cstrongu003eDNS records:u003c/strongu003e current A, CNAME, MX, and TXT records documented in full before any changesu003c/liu003eu003cliu003eu003cstrongu003eSSL certificate status:u003c/strongu003e expiry date and certificate authorityu003c/liu003eu003cliu003eu003cstrongu003ePerformance baseline:u003c/strongu003e current load time and Core Web Vitals scores to compare against after migrationu003c/liu003eu003c/ulu003eu003cpu003eRunning a structured pre-migration audit across your fleet, rather than ad hoc per project, also surfaces patterns you can act on at scale. See u003ca href=u0022/blog/how-to-run-a-wordpress-site-audit-across-your-entire-client-fleet/u0022u003ehow to run a WordPress site audit across your entire client fleetu003c/au003e for the fleet-level version of this process.u003c/pu003e

u003cpu003eCutover failures are rarely caused by the migration itself. They are caused by missing access discovered mid-move, when the cost of stopping is highest.u003c/pu003eu003cpu003eConfirm every item below at least 48 hours before your scheduled cutover window:u003c/pu003eu003culu003eu003cliu003eSSH or SFTP credentials to both source and destination servers, tested and confirmed workingu003c/liu003eu003cliu003eWordPress admin credentials for both source and destination environmentsu003c/liu003eu003cliu003eDatabase access on the destination: host, port, database name, username, and password all verifiedu003c/liu003eu003cliu003eDNS registrar login confirmed and TTL lowered to 300 seconds at least 24 hours before cutoveru003c/liu003eu003cliu003eEmail routing on destination: SMTP settings, MX records, and any transactional email service API keysu003c/liu003eu003cliu003eA staging environment on the destination host with a temporary domain for full testing before DNS switchu003c/liu003eu003cliu003eA complete backup of the source site, taken within 24 hours of cutover, stored independently of both hostsu003c/liu003eu003c/ulu003eu003cpu003eIf the destination is a managed WordPress hosting environment built for agencies, confirm explicitly which responsibilities the host handles at the server level (backups, SSL provisioning, object caching) and which remain yours. Document the boundary. Assumptions here create gaps that only appear after the site is live on the new host.u003c/pu003e

u003cpu003eThe cutover phase is where most migration errors are introduced, and where a checklist earns its keep. Run these steps in sequence. Do not skip a step because a prior migration went cleanly.u003c/pu003eu003cpu003eu003cstrongu003eFile and database transfer:u003c/strongu003eu003c/pu003eu003culu003eu003cliu003eExport the database from source using a method that handles large tables without timeout (WP-CLI or phpMyAdmin with chunked export)u003c/liu003eu003cliu003eTransfer all files, including hidden files such as .htaccessu003c/liu003eu003cliu003eImport the database on destination and verify row counts match the source exportu003c/liu003eu003cliu003eUpdate wp-config.php with destination database credentialsu003c/liu003eu003cliu003eRun a search-replace for all URLs using a tool that handles serialized data correctly, not a raw SQL replaceu003c/liu003eu003c/ulu003eu003cpu003eu003cstrongu003eStaging verification before DNS change:u003c/strongu003eu003c/pu003eu003culu003eu003cliu003eTest all major page types: home, archive, single post, single page, and any commerce or membership pagesu003c/liu003eu003cliu003eSubmit every form type and confirm delivery end-to-endu003c/liu003eu003cliu003eConfirm user login and registration flows function correctlyu003c/liu003eu003cliu003eVerify all third-party Connectors fire correctly using browser developer tools to check network requestsu003c/liu003eu003cliu003eRun a crawl for broken internal linksu003c/liu003eu003cliu003eConfirm SSL is active and enforced on the destination domainu003c/liu003eu003cliu003eConfirm redirects from any changed URL structures are in placeu003c/liu003eu003c/ulu003eu003cpu003eDo not proceed to DNS cutover until every staging verification item passes. A failed check on staging takes minutes to fix. The same failure discovered after DNS propagation takes much longer and affects real visitors.u003c/pu003e

u003cpu003eDNS cutover timing determines how much data divergence your client’s site accumulates during the move, and how long visitors see an inconsistent state.u003c/pu003eu003cpu003eBefore flipping DNS, confirm that your TTL reduction from the pre-flight phase has propagated fully. With TTL at 300 seconds, most resolvers will pick up the new A record within five to ten minutes of the change.u003c/pu003eu003cpu003eEnable WordPress maintenance mode only during the window when the live database on the source host is frozen for final export. For most migrations, this window is under 30 minutes. Maintenance mode beyond that window costs the client real traffic and should be avoided unless the site has an active transaction layer (e-commerce, membership, booking) where data divergence between source and destination would cause genuine loss.u003c/pu003eu003cpu003eCommunicate the cutover window to the client before it starts: an exact start time, an expected duration, and a direct contact for the operator running the move. Do not give an estimate range for maintenance mode. Give a specific time and hold to it. Vague windows create unnecessary support escalations.u003c/pu003eu003cpu003eAfter the DNS change, monitor propagation from multiple geographic locations using a DNS propagation checker, and watch traffic on the source server drop off to confirm the switch is complete before decommissioning or repurposing the source environment.u003c/pu003e

u003cpu003eThe post-migration audit is not optional, and it is not a quick visual check. It is a structured verification pass that compares the live destination site against the baseline captured in the pre-migration audit.u003c/pu003eu003cpu003eRun these checks within two hours of DNS propagation completing, while you still have access to the source environment:u003c/pu003eu003culu003eu003cliu003eu003cstrongu003ePerformance:u003c/strongu003e run a fresh Core Web Vitals measurement and compare against the pre-migration baseline. Regressions almost always trace back to caching not configured or object cache not connected on the new host.u003c/liu003eu003cliu003eu003cstrongu003eSearch indexing:u003c/strongu003e confirm Google Search Console has the destination domain verified and submit a fresh sitemap. Check that no noindex tags from the staging configuration carried over to production.u003c/liu003eu003cliu003eu003cstrongu003eEmail delivery:u003c/strongu003e send a test from every contact form and a test transactional email (password reset, order confirmation) and confirm delivery, including a spam folder check.u003c/liu003eu003cliu003eu003cstrongu003eSSL and security headers:u003c/strongu003e run the destination domain through an SSL checker and an HTTP headers inspector. Confirm HTTPS redirects are enforced and that HSTS is present if it was present on the source.u003c/liu003eu003cliu003eu003cstrongu003eAnalytics and tracking:u003c/strongu003e confirm your analytics platform is receiving sessions on the destination domain and that no duplicate tracking is firing.u003c/liu003eu003cliu003eu003cstrongu003eBroken links:u003c/strongu003e run a full crawl of the destination and export any 4xx responses for immediate resolution.u003c/liu003eu003cliu003eu003cstrongu003eBackup configuration:u003c/strongu003e confirm the destination host’s backup schedule is active and that at least one post-migration backup exists before closing the ticket.u003c/liu003eu003c/ulu003eu003cpu003eDocument the result of each check with a pass or fail and a timestamp. This record is your proof of completion if anything is disputed weeks later.u003c/pu003e

u003cpu003eA checklist used once is a document. A checklist used on every migration is a runbook, and the difference is in how you store it, version it, and assign it.u003c/pu003eu003cpu003eStore the runbook in a format that can be templated per client. Each migration gets its own instance, pre-populated with client-specific details (source host, destination host, primary domain, DNS registrar), with the steps identical across all instances. Name each instance with a consistent convention, such as client shortcode, date, and migration type, so your team can find prior runs when a client question surfaces months later.u003c/pu003eu003cpu003eReview the runbook after every migration. If a check caught something real, keep it. If a step was consistently skipped without consequence, remove it. A runbook that grows without pruning becomes noise. The goal is a checklist your team can complete without referring back to documentation for every item.u003c/pu003eu003cpu003eFor agencies operating on managed WordPress hosting for multiple clients, the runbook should also document what the host provides automatically so operators do not duplicate those steps or, worse, assume coverage that is not there. The runbook is the operating memory of your migration practice, not any one team member’s personal knowledge.u003c/pu003eu003cpu003eWhen migrations run consistently and every step is auditable, they become a commodity service your agency can price, staff, and hand off without the founding team in the room. That is the compounding return of treating your WordPress migration checklist as a permanent operating layer, not a one-time project artifact.u003c/pu003e