How We Migrate WordPress Websites Without Avoidable Downtime

A safe WordPress migration is a controlled production change

To migrate WordPress without avoidable downtime, prepare and test the destination before public traffic moves, identify every dependency that can affect the website, choose how changing data will be synchronized, make the DNS and certificate path reversible, and verify the live application after cutover. Copying files and importing a database are necessary steps, but they are not the migration plan.

A production WordPress platform can depend on application files, database content, media, DNS, TLS certificates, email delivery, cron, caching, redirects, custom code, analytics, payment or membership services, API credentials, and people at several vendors. A cutover can appear successful while forms stop delivering mail, scheduled tasks disappear, a stale IPv6 record serves the wrong environment, or a domain change damages important URLs.

Osiris uses an evidence-led sequence: discover, stage, compare, synchronize, cut over, verify, and monitor. The objective is to reduce avoidable interruption and data loss without making a universal zero-downtime promise. Organizations choosing a provider can review our WordPress migration and technical cutover service; this field note explains the operating method behind it.

Choose the migration pattern before choosing the tool

The right method depends on what is changing. A migration plugin can be useful, but it cannot decide which records are authoritative, whether the source is trustworthy, who controls DNS, or what should trigger rollback. We classify the move before selecting the transfer mechanism.

A host-to-host move that preserves every public URL usually does not require a search-engine Change of Address. A domain or URL migration does. Google’s official site-move guidance recommends testing the new site, mapping old URLs to final destinations, using server-side permanent redirects, updating canonicals and internal links, and monitoring the transition. Those tasks belong in the migration scope whenever public URLs change.

Build a migration manifest that defines the whole system

The migration manifest is the shared inventory, ownership map, scope boundary, and verification plan. It prevents the project from shrinking into “files and database” while dependencies remain implicit.

Application: WordPress version, themes, child themes, plugins, must-use plugins, drop-ins, custom plugins, custom integrations, PHP requirements, database engine and version, rewrite rules, environment constants, object cache, page cache, cron, command-line tasks and deployment process.

Data: database size and tables, media paths, offloaded storage, generated files, users and roles, application passwords, ecommerce or membership records, form storage, search indexes, queues, logs and exports. Each item is marked as durable business data, rebuildable output, historical evidence, or out of scope.

Delivery: domain registrar, authoritative DNS, CDN or reverse proxy, apex and www records, AAAA records, CAA policy, TLS issuance and renewal, HTTP redirects, caching rules, security headers, email delivery, SPF/DKIM/DMARC ownership, analytics, consent tooling, webhooks and external APIs.

People and control: who can authorize the move, who controls each service, who will be available during cutover, and who owns a failed check. Credentials are exchanged through an approved secure channel—not through a public form or ordinary working notes.

The official WordPress migration handbook reinforces the need to back up application files and the database, adapt configuration for the destination, verify site addresses, and account for rewrites and URL changes. Our manifest extends that application guidance into the operating dependencies that determine continuity.

Build and test the destination while production remains authoritative

The destination is provisioned separately with its own system user, database, runtime configuration, web server, access controls, backup path, cache configuration and logging. Existing websites on a shared server remain out of scope and must not be disturbed.

Where direct transfer is practical, source archives are copied privately and their size and SHA-256 checksum are recorded. Large archives are protected from public retrieval before restoration. Database credentials and WordPress salts are created for the destination rather than copied into logs or chat. If the source is compromised or its integrity is uncertain, the project becomes a controlled reconstruction: clean WordPress core and trusted extensions are installed from known sources, business data is reviewed separately, and suspicious executables are not imported merely because they were present.

The restored site is tested through a controlled hostname or local resolution while public DNS still serves the original environment. Validation covers representative templates and devices, administration and authentication, forms and outbound mail, password reset, search, REST endpoints, cron, redirects, media, custom functionality, security controls, caching, database health and error logs.

A homepage comparison is not enough. The test list follows the organization’s actual critical journeys and the manifest. It also records pre-existing defects so the migration is not blamed for old behavior—and genuine destination defects are not dismissed as “probably already there.”

Protect changing data with a final synchronization decision

The first database copy becomes stale as soon as production changes. The final synchronization plan must be chosen before cutover, based on where authoritative writes occur and how they can be reconciled.

• Mostly static publishing site: use a short editorial freeze, copy the current database and any new uploads, then verify modification times and content counts.
• Lead-generation site: identify whether submissions live in WordPress, email, a CRM, or several places; test delivery and retain any submissions received during the transition.
• Ecommerce, membership, booking or community site: document orders, accounts, sessions, inventory, subscriptions and webhooks; choose incremental synchronization, a narrow write freeze, reconciliation, or a platform-specific transition.
• Large media or database estate: complete the bulk transfer early, then synchronize only changed durable data where the tools and architecture support it.

Repeating a full import automatically is not safer. A second restoration can overwrite destination corrections, reintroduce incompatible configuration, or erase new data. The evidence should determine what changed after staging and what must be synchronized.

When application URLs or paths change, WordPress serialized values must be handled safely. The official WP-CLI search-replace documentation explains that the command handles PHP serialized data and supports a --dry-run. We dry-run broad replacements first, review the affected tables, avoid changing primary identifiers, and narrow production writes to application data rather than blindly rewriting security or telemetry history.

Prepare DNS, TLS and search controls before the cutover

A migration should not discover its certificate strategy after traffic reaches the new server. When DNS-01 validation is available, domain control can be proven with a temporary TXT record while the original website remains live. The Let’s Encrypt challenge documentation describes how DNS-01 validates control through DNS. Issuance is only part of the job: renewal, challenge routing and the web-server reload path must also be sustainable.

Before the DNS change, record the authoritative nameservers, apex and www records, relevant AAAA records, current TTL, CDN or proxy status, CAA policy and the known-good former values. Change instructions should identify only the records in scope. Nameservers, MX, SPF, DKIM, DMARC, verification records and unrelated subdomains are preserved unless the approved project explicitly includes them.

If public URLs change, prepare a one-to-one URL map, direct permanent redirects, new self-referencing canonicals, updated internal links and a new sitemap. Avoid redirect chains and irrelevant redirects to the homepage. Google advises keeping permanent redirects for at least a year and updating important internal and external links to their final destinations.

Staging access controls or noindex directives must be removed from the public destination at launch. Conversely, a private staging hostname should not become indexable merely because production cutover has finished.

Use an explicit cutover and rollback checklist

Cutover is a decision point with owners, success conditions and a stop point. Immediately before proceeding, the responsible people confirm:

• the destination build and critical-journey tests passed;
• fresh database and file backups exist and their locations are known;
• the final synchronization or write-freeze procedure is complete;
• the destination certificate, redirects and host configuration are ready;
• the exact DNS, proxy or routing changes are written down;
• the previous values and source environment remain available for rollback;
• the monitoring and communication channels are active; and
• the person authorized to proceed has approved the change.

Rollback is triggered by defined material failures—not by unease and not only by a blank homepage. Examples include loss of authoritative writes, failed checkout or authentication, broken administration, unresolved certificate errors, critical integrations failing, or a destination fault that cannot be corrected safely inside the agreed window.

The source remains intact during the rollback period, but it should not accept uncontrolled writes after authority has moved. The team must know which environment is authoritative at every stage. DNS propagation can create an overlap period; logs, resolver checks and response markers help establish which system is serving each test.

Verify production with evidence, then monitor the overlap

After the change, test the real public hostname through the real delivery path. Confirm HTTP-to-HTTPS behavior, www or apex canonicalization, certificate chain, representative URLs, images and scripts, forms, outbound mail, login and password reset, REST endpoints, cron, database health, caches, redirects, analytics, consent, webhooks, disk and memory condition, and recent server and PHP errors.

For a same-URL infrastructure move, verify that crawlers receive the intended status, canonical and index directives and that the sitemap remains available. For a URL-changing move, test the redirect map, canonicals and internal links, submit the appropriate sitemap, and use Search Console to monitor the transition. Google notes that search visibility can fluctuate during a site move; a responsible provider should not promise preserved rankings as a guaranteed outcome.

The former host is retired only after the monitoring and rollback window closes and someone confirms it does not also contain mail, another website, a shared database, backups, scheduled jobs or other resources that must remain. Credentials and temporary access are reviewed, destination backups and renewal paths are verified, and unresolved findings are assigned rather than hidden inside a generic “migration complete” message.

What two controlled migrations reinforced for Osiris

Osiris applied this operating pattern across two independent WordPress environments with different hosting histories and constraints. The common principle was to build and validate the destination before asking public traffic to use it. We transferred source packages privately, recorded integrity evidence, tested through controlled resolution, prepared certificates ahead of public cutover, narrowed DNS instructions to the website records, kept the previous environments available during rollback windows, and repeated the public journey after traffic moved.

The work reinforced three practical lessons. First, production and staging should be compared from evidence rather than memory; an unnecessary re-import can create more risk than it removes. Second, cache behavior and email delivery are part of the application outcome. A fast page with lost form notifications is not a successful migration. Third, the clean exit matters: the former environment should not remain indefinitely as an unmanaged copy of the organization’s website.

For a detailed anonymized example, read the large WordPress platform migration evidence record. For the operating discipline after launch, see what proactive WordPress maintenance includes.

If your WordPress platform needs to move between hosts, servers, domains or runtime generations, review the migration service scope or request a migration-readiness review. Send the public URL, current environment type if known, intended destination, timing, and whether the site accepts changing data. Do not send passwords, private keys, database exports, backup archives or customer information through the public form.