Plan WordPress Copies and Migration by State and Custody

Inventory what a move touches

Files and database are separate parts

Start with the WordPress installation itself. A typical recovery involves files—core, themes, plugins, uploads and configuration as applicable—and the separate database. WordPress describes these as two parts of a site backup: files do not contain the database, and the database does not contain the code and files used to render the site. A WP-CLI database export is useful evidence for one component, not a complete site copy. The WordPress guidance treats the files and database as a set and describes an order for backing up and restoring them; that guidance does not certify a particular product’s capture consistency or your ability to use its artifacts.

Name state outside WordPress

Make separate rows for anything the site relies on but that may live elsewhere: mailboxes and outbound mail routing, DNS zone and registrar access, object storage, queues, payment or other APIs, credentials and encryption keys, scheduled jobs, and plugin or theme licenses. For each, ask whether it is copied, recreated, transferred by an account owner, or deliberately left behind. Files and database do not imply that these items move with them. For a shop receiving orders, also identify payment and notification systems that may observe a write independently of the WordPress database. This is an inventory question, not a claim that any such service is configured.

Use one row per component and copy

Duplicate this register row for every source component and every destination copy. Record facts from a named document or account record; otherwise mark them unknown.

Example prompts, not observations: Does “site backup” include the database? Does the production owner also control the copy’s deletion key? Record evidence or unknown. The WordPress VPS ownership map places this decision in the wider operating plan.

Separate owner goals from promises

Set recovery objectives as owner goals

Before choosing a copy schedule, ask what accepted work the owner could tolerate re-entering and how soon service must return. Recovery point and recovery time objectives are owner goals for a workload and scenario. The accepted evidence supplies no value for your site, provider commitment, or measured recovery time. A cadence or “daily” label does not prove that a goal is met.

Worksheet: acceptable loss window __________; required functions __________; owner-chosen target time __________; scenarios __________; approving owner/date __________. If no goal is chosen, record “not set”; do not claim the copy is adequate.

Ask what independence actually means

For each copy, record its location, failure domain, account owner, retrieval/deletion actors, credentials, key custody, retention authority, and post-cancellation access. Ask whether production compromise, key loss, suspension, or an administrator’s departure also removes access. A remote location does not prove independent custody; a snapshot label does not establish that files, database, and external state form one application-consistent point. Verify scope and access terms against the selected contract or account evidence.

Record each answer with source/date: location __________; failure domain __________; who can retrieve/delete __________; separate credentials or keys __________; retention and post-cancel access terms __________. Unknown answers are unresolved dependencies, not presumed protection.

Name a future verifier; do not imply a drill

Identify who could validate the artifacts and what authority that person would need. File existence or a successful export command does not show that a site can be restored. A restore drill is a separate future operation requiring explicit owner authorization, a suitable environment, access to secrets, and a defined check and cleanup plan. No drill or restore occurred for this guide. Until an authorized operator records evidence, enter “not verified,” not “tested.”

Assign each copy a custodian and path

Record custody, retrieval, and last verification

For every file copy, database copy, and external-state export, identify a human or role accountable for custody. Add the actual location and failure domain; destination account owner; who holds keys and MFA recovery; who authorizes retrieval; who can delete from root or production access; the documented retention authority; file or database format; dependency on software or credentials; access after cancellation; and any last verification record. If verification has not occurred, say so and date the blank. Do not invent retention or infer a retrieval path from a control-panel feature page.

Add retrieval approval __________; key-loss recovery owner __________; cancellation effect and cited term __________; format evidence __________; last verification __________. These entries do not assert that a vendor offers the capability.

Keep application scope distinct from panel features

Name files and database separately, then list mail, object storage, queues, DNS and other external state. A panel may offer a feature called backup, but that alone does not establish which volumes it covers, whether database and files are coordinated, whether storage is outside the production failure domain, or whether credentials remain usable after cancellation. This page addresses WordPress state and migration. The existing backups versus snapshots policy page owns broader terminology and provider-product distinctions; its exact section anchor has not been audited, so this link intentionally uses the route only.

Treat loss of access as a stop condition

Ask whether cancelling hosting, losing a key, losing an administrator, or a production compromise could also remove copy access. If the answer is unknown, do not count that copy toward the owner’s recovery objective until its custodian and retrieval path are established. For the related clocks and post-cancellation access decision, see the lifecycle page’s access and custody questions. That page owns exit timing; this page owns the copy register.

Relate files and database around writes

Choose an authoritative state for mutable data

WordPress files and its database can change independently. A store or membership site may receive database writes while files are copied, so captures from unrelated times can represent different moments. This is operational reasoning from the separate files/database model, not a guarantee about a capture tool.

Ask which accepted order, enrollment, or content state is authoritative at cutover. The operator should identify whether an authorized write freeze or repeatable final sync is possible, what database/media deltas remain, and how webhooks, queues, payments, or mail relate to the cutoff. Choose an approach for the actual write behavior and authority; no universal maintenance interval is prescribed.

Write down the cutoff and resumed-write boundary

Stop when versions cannot be reconciled

Stop the planned cutover if the source and destination timestamps cannot be related, the owner cannot identify the authoritative version, a write path is unaccounted for, or the person authorized to preserve the original is unknown. Do not overwrite a live database with an older copy merely because a migration step is ready. Escalate the unresolved state to the business owner and operator; revise the plan and record a new decision before any separately authorized production action. There is no blanket rollback operation: the safe response depends on which copy is authoritative and what writes have already occurred.

Scope WordPress-aware transformation

Review database export and URL transformation scope

WP-CLI documents wp db export as a database export using the database parameters configured in wp-config.php. Protect both the dump and credentials as sensitive material. An export does not include the WordPress files or separately hosted services. For URL or domain changes, WP-CLI’s search-replace command says it handles PHP serialized data; plain SQL string replacement can damage serialized lengths. Its --dry-run option reports without saving, while --export writes transformed data to SQL rather than modifying the database. Multisite defaults to current-site tables unless --network is specified.

These behaviors scope a review; they are not instructions to run a production command. Before a separately authorized change, an operator must review site/network scope, source and destination values, access, preservation authority, and the exact command plan. Dry-run output does not prove every plugin setting or external dependency is correct.

Reconcile what commands do not move

Make an explicit checklist of old and new URLs/domains, uploads and paths, configuration, database credentials, plugin licenses and domain activations, cron or scheduled work, mail routing, APIs and secrets, caches, DNS, and any network-wide tables or domain mappings. Mark each as copied, transformed, reissued, recreated, intentionally unchanged, or unresolved. A database string replacement does not move mail, DNS, credentials, licenses, queues, or an external object store. For multisite, name which sites and tables are in scope rather than assuming a single-site default applies.

Define checks and approval before a future move

The owner should choose representative checks for the actual site: administrator login, expected content and database records, media rendering, one approved read/write path, forms or checkout, scheduled jobs, mail handoff, URLs, permissions, and any integrations that matter. Assign an accountable verifier and decide what discrepancy blocks acceptance. These are candidate checks, not results; no site, database, mail flow, or URL was tested here. Stop if credentials are missing, transformed scope is unclear, a critical expected record is absent, or the verifier cannot explain the evidence needed for approval.

Plan a bounded move with verification

This planning runbook was not executed. Fill each owner, evidence field, and stop gate before separately authorizing operational work.

1. Assign authority and endpoints.

   Source ____________________; destination ____________________; business decision owner ____________________; migration operator ____________________; database owner ____________________; files/copy owner ____________________; DNS owner ____________________; mail owner ____________________; approval channel ____________________. Confirm how each operator receives credentials without putting secrets in this worksheet. Stop if destination ownership, change authority, or preservation authority for the source is unclear.

2. Complete state and custody.

   Attach the filled component/copy register. For every copy, cite exact retention terms if available; otherwise write “unknown.” Record owner-selected loss and restore-time goals separately from any contract. Stop if essential external state, copy access, key custody, or a required dependency has no owner.

3. Define the write cutoff.

   Record last accepted write, jobs/webhooks to pause or account for, DB and file capture relationship, media or database deltas, external state, final sync owner, and when writes resume. Identify who decides the authoritative version. Stop if the parties cannot relate the cutoffs or protect newer production writes from stale overwrite.

4. Review transformation before production changes.

   List old/new URLs, single-site or network scope, serialized-data handling, credentials, licenses, integrations, and the intended import/search-replace plan. The responsible operator reviews any dry-run or export artifact and confirms which steps would write. Stop on unknown table scope, unreviewed secret handling, or a transformation that cannot be reversed under the agreed authority. No command is run by this guide.

5. Set acceptance evidence.

   Owner-selected checks ____________________; expected result/source ____________________; verifier ____________________; evidence record location ____________________; unacceptable discrepancy ____________________. Capture results only after a future authorized action. If a check is omitted or evidence unavailable, record “not verified”; stop acceptance when a required check fails or conflicts with the authoritative source.

6. Set retention, rollback authority, and deletion decision.

   Who may authorize rollback ____________________; which version they would preserve ____________________; retention basis and end condition ____________________; who decides source/copy deletion ____________________; verification required before deletion ____________________. Do not delete the original or a needed copy before owner verification and an explicit decision. No fixed retention duration, disk multiplier, elapsed migration time, or successful outcome is assumed.

Unresolved gates leave the plan incomplete; they do not authorize an improvised cutover. A future operator records actions, timestamps, deviations, evidence, and approvals. This manuscript records no operational event.

Route unresolved work to its owner

Hand off clocks, selected expenses, and broad policy

Use the lifecycle page’s access-clock section for cancellation timing and who retains access after exit; return here when its answer names the copy custodian. For an actual selected copy or migration charge, take sourced cash inputs to the cost page’s copy-expense worksheet; do not estimate missing prices or labor here. The WordPress VPS hub maps the broader ownership decisions. The existing backups/snapshots policy route owns general taxonomy and product distinctions; this article owns the WordPress state register, file/database relationship, custody and cutover decisions.

When a contract, account screen, or custodian answer is missing, state the missing document and who will obtain it. Do not fill the gap with a provider assumption. Return to this page with component, exact scope, custodian, retrieval condition, verification owner/date, and rollback authority. Those fields make the next decision reviewable while keeping unknown outcomes visibly unknown.

Return a useful custody record

For each component, carry forward: name/scope __________; copy location and failure domain __________; custodian __________; retrieval condition __________; contract or evidence source/date __________; last verification and verifier __________; unresolved dependency __________; rollback authority __________. The return link from the lifecycle route points to this page’s copy-custody register. The hub return is the hub’s backup and recovery ownership checkpoint.

Sources, limits, and recheck

Research checked 2026-11-06. Recheck primary owner documentation and the exact selected contract or account terms before publication or any future operation; upstream pages and product terms can change. No provider, server, account, WordPress install, database, or copy was inspected for this page.

• WordPress Advanced Administration Handbook: Backing Up Your WordPress Files (C001; captured 2026-11-06, rendered text excerpt). Supports the distinction between files and database and describes a typical backup/restore relationship; does not establish a selected product’s consistency, retention, independence, or successful recovery.
• WP-CLI command reference: wp db export (C002; captured 2026-11-06, rendered text excerpt). Describes database export and configured database parameters; it is not a full-site copy.
• WP-CLI command reference: search-replace (C003; captured 2026-11-06, rendered text excerpt). Documents serialized-data handling, dry-run/export behavior, and multisite table scope; not an endorsement or validation of commands against a live site.

Evidence status: the guidance is primary-source material, but the accepted captures are rendered excerpts rather than original HTTP response bytes. Reopen the live owner pages and selected contract terms before making current claims. The worksheet is planning logic, not evidence that a copy exists or works.

Page status: Draft — verify before publish. No restore, migration, benchmark, account test, or other operational action is claimed.