A WordPress site migration checklist for agencies is not a project plan. It is a runbook: a fixed sequence of pre-flight checks, cutover steps, and post-migration audits you run the same way on every client site. Structure it that way and every move becomes faster, more consistent, and easier to hand off to any trained operator on your team.
Every 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.
Most 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.
A 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.
Structuring 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.
A 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.
Before touching any file or database, capture and document:
Running a structured pre-migration audit across your fleet, rather than ad hoc per project, also surfaces patterns you can act on at scale. See how to run a WordPress site audit across your entire client fleet for the fleet-level version of this process.
Cutover failures are rarely caused by the migration itself. They are caused by missing access discovered mid-move, when the cost of stopping is highest.
Confirm every item below at least 48 hours before your scheduled cutover window:
If 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.
The 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.
File and database transfer:
Staging verification before DNS change:
Do 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.
DNS cutover timing determines how much data divergence your client’s site accumulates during the move, and how long visitors see an inconsistent state.
Before 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.
Enable 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.
Communicate 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.
After 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.
The 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.
Run these checks within two hours of DNS propagation completing, while you still have access to the source environment:
Document 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.
A 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.
Store 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.
Review 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.
For 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.
When 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.
A complete WordPress migration checklist for agencies should cover four phases: a pre-migration audit (documenting the source environment, plugins, DNS, and performance baseline), pre-flight checks (verifying access credentials, staging environment, and backup), a cutover checklist (file and database transfer, staging verification, DNS switch), and a post-migration audit (performance comparison, email delivery, SSL, analytics, and broken link checks). Each phase should end with a signed-off record so the migration is auditable after the fact.
Agencies reduce migration errors by treating each move as an instance of a repeatable runbook rather than a one-off project. A fixed sequence of documented steps, run identically on every client site, removes the variability that causes errors. It also means any trained operator can run the migration, not just the person who originally built the site. The runbook should be reviewed and refined after every migration to incorporate anything new that was caught.
Enable WordPress maintenance mode only during the final database export window on the source host, when you need to freeze live data to prevent divergence between source and destination. For most migrations this window is under 30 minutes. Avoid extended maintenance mode beyond that window, as it costs real traffic. Communicate the exact start time and expected duration to the client in advance.
A post-migration audit compares the live destination site against the baseline captured before the migration. It checks Core Web Vitals against the pre-migration benchmark, email delivery from all form types and transactional triggers, SSL and HTTPS enforcement, Google Search Console verification and sitemap submission, analytics receiving sessions on the new domain, and a full crawl for broken links or 4xx responses. Each item should be documented with a pass or fail and timestamp before the ticket is closed.
A standard WordPress migration guide walks through the steps for a single site move. A migration runbook is a templated, versioned document designed to be run identically on every client site your agency migrates. It includes client-specific fields pre-populated at the start of each instance, a signed-off record for every phase, and a naming convention that lets your team find prior migration records by client. The runbook is maintained and refined over time, making each migration faster and more consistent than the last.
200 free credits. Just describe what you need.
See It In Action