A WordPress migration is complete when the intended site works on the destination, current records are preserved, customer services still connect, and the old environment can be retired safely. Copying files is only one part of that work.
Use this WordPress migration checklist to separate three situations: a hosting move that keeps the same URLs, a move that changes domains or paths, and a transactional site that continues collecting orders, bookings, or leads during preparation. Each requires a slightly different launch plan.
The practical sequence is to inventory the current system, preserve recoverable backups, rehearse the move privately, define the final data boundary, switch the necessary routing, and verify both application behavior and business records. Keep rollback available until the evidence supports retirement of the old system.
Choose the correct migration branch
A hosting-only move changes where the application runs while keeping its public addresses. A URL-changing move also changes what customers and search engines request. An active-store move adds the problem of preserving transactions that occur while the destination is being prepared.
These branches can overlap. A store moving to a new domain needs all three considerations. A small brochure site moving between hosts with the same domain may need no new page redirects at all.
| Migration condition | Additional work to plan |
|---|---|
| Hosting changes, URLs stay identical | Destination compatibility, routing, certificates, application and integration checks |
| Domain or paths change | URL mapping, permanent redirects, canonical links, sitemaps, and search monitoring |
| Orders or other records continue changing | Final synchronization, control of writers, external reconciliation, and one authoritative application |
| Multisite or custom architecture | Network-aware tooling, domain mapping, shared data, and specialist review |
The WordPress migration handbook covers different movement scenarios. Apply the relevant procedure to the actual installation rather than assuming every WordPress site has the same directory and database layout.
Define success before scheduling the move
List the website’s essential outcomes. A service business may need working quote forms, accurate content, and reliable email delivery. A store needs correct products, checkout, payments, orders, inventory, and fulfillment communication.
Turn each outcome into an acceptance check. “Contact page opens” is weaker than “a controlled inquiry reaches the intended mailbox and CRM.” “Checkout loads” is weaker than “a supported test order has the expected total and state.”
Name the business decision-maker, technical operator, hosting contact, and person responsible for DNS. Give one coordinator responsibility for the timeline and launch decision. Several capable people can work together without making simultaneous undocumented changes.
Record the conditions that stop launch or trigger rollback. Examples include missing current orders, a failed payment callback, an incorrect production database, or a certificate problem. A predefined stop condition is easier to follow than a decision made while customers are waiting.
Inventory the current site and surrounding services
Record the domain registrar, authoritative DNS provider, hosting account, content delivery network, mail service, backup storage, and critical external integrations. Store credentials in the approved password manager, not in the migration worksheet.
Inside WordPress, identify core, theme and child theme, plugins, must-use components, drop-ins, custom code, uploads, and database configuration. Include files or application data outside the normal content directory.
The Site Health screen can help gather configuration details. Review the report before sharing it because it can reveal infrastructure information.
Also identify custom server behavior: redirects, access rules, scheduled jobs, PHP extensions, upload limits, and environment variables. A plugin archive may copy application files without reproducing those settings.
Separate domain registration, DNS, hosting, and email
These services may be purchased from one company but perform different jobs. Moving website hosting does not necessarily require transferring the domain registration, moving mailboxes, or changing nameservers.
Choose the smallest routing change that meets the plan. If only web hosting changes, updating the relevant web records may be sufficient. If nameservers change, the entire required DNS zone must be recreated and verified, including mail and verification records.
Coordinate DNSSEC with the registrar and DNS provider when authoritative service changes. An incorrect delegation or stale security relationship can affect the whole domain. Have the responsible provider handle its documented transition rather than toggling unfamiliar settings at random.
List the services that depend on the domain: business email, transactional sending, authentication, calendars, verification records, and subdomains. Their owners should confirm the intended state before launch.
Preserve a recovery set and a current-state record
Back up files and database through a supported method. The WordPress file-backup guide and database-backup guide explain why both components matter.
Confirm that the material is readable and accessible outside the sole environment being moved. Record the recovery-point time, time zone, tool, scope, and any archive-chain or encryption dependencies.
Keep the source site intact during preparation. A successful export is not a reason to delete the original application immediately. You may still need missing media, recent transactions, or configuration evidence.
Capture a baseline of important URLs, response behavior, titles, canonical links, indexing settings, and relevant performance observations. This is a comparison record, not a promise that search traffic will remain unchanged.
Preserve data that a standard copy may omit
Check external media storage, downloadable products, custom directories, server-managed secrets, and integration queues. Confirm what the selected migration tool includes and excludes.
A WordPress content export is useful for supported content movement but is not a full-site backup. Likewise, a database export does not contain the actual media files referenced by attachment records.
For a custom application, ask the developer which artifacts are required to run it and which are required to maintain it. Production may use generated assets while future maintenance also needs the source and build process.
Check destination compatibility before copying production
Confirm a supported web PHP runtime, required extensions, database compatibility, storage headroom, file ownership, and the host’s application limits. Use the actual web environment, which can differ from a command-line shell.
Consult the PHP supported-versions page and the requirements of critical components. Avoid combining a migration with several unrelated major upgrades unless the project deliberately includes them and tests the resulting combination.
A move can expose an existing dependency that the old server happened to satisfy. For example, a custom image-processing feature may require an extension absent on the destination. Identify that before changing public routing.
Check host-specific plugins and drop-ins. Some should be replaced or configured by the destination host; others may be essential to the source environment. Do not copy every infrastructure integration blindly or delete host-managed code without understanding ownership.
Plan certificates and secure access in advance
The destination should serve the intended hostname securely when traffic arrives. Use the host’s supported certificate-validation process, which may offer a method that does not require premature public routing.
Testing an IP address alone does not reproduce the correct hostname, certificate, and virtual-host behavior. Use an approved preview or local-resolution method that preserves the intended request context where possible.
Do not bypass certificate warnings and count the result as a successful HTTPS test. Verify the final public hostname, redirect behavior, certificate validity, and application URLs through the intended route.
Choose a migration method you can verify
A host-managed service, a compatible migration plugin, or a qualified manual process can all be suitable. Select according to site size, architecture, supported data, downtime constraints, and operator capability.
Read the tool’s current limits for multisite, large databases, external storage, custom tables, and transactional synchronization. A marketing claim of a one-click move does not specify every application boundary.
A manual process gives control but also requires precise destination checks and recovery planning. This guide does not provide a generic destructive database-import command because the wrong target can overwrite the live application.
Keep operation logs and identifiers. If a copy stops partway, preserve the error and determine which stage failed before retrying. A partially working homepage is not proof that the entire migration completed.
Rehearse the destination privately
Create a protected destination and confirm that it uses the intended separate database and paths. Prevent customer emails, real payments, inventory writes, and other external actions before the copied application begins running normally.
A staging label or hostname is not a universal safety switch. A clone can retain production credentials and scheduled actions. Record each integration’s test mode, blocked route, or controlled destination.
Check representative content, media, administration, forms, commerce, and role-based access. Record environmental differences such as cache behavior, resources, external domain approval, and callback availability.
A rehearsal should answer whether the chosen method reproduces the application and whether the launch procedure is practical. Keep unfinished design changes separate from the migration unless they are intentionally in scope.
Build a URL map when addresses change
Create a list of old URLs and their intended new destinations. Include important landing pages, posts, products, categories, downloads, and campaign destinations, not just navigation items.
Preserve existing URLs where they still make sense. When a URL must change, map it to the closest equivalent content. Do not send every removed page to the homepage merely to avoid a visible missing-page response.
Use the appropriate permanent server-side redirect for a permanent move. Test representative mappings for correct status, destination, content, and unnecessary chains. Google’s URL-changing site-move guidance explains the search-engine side of this process.
Update internal links, canonical URLs, sitemap entries, and relevant structured data to reference the final addresses. Redirects help incoming requests, but they are not a reason to leave the site’s own links pointing through avoidable detours.
Treat unchanged URLs differently
When the domain, protocol, and paths remain identical, there is no new page address to redirect to simply because the server changed. Preserve the existing canonical and response behavior while moving the application.
Google provides separate hosting-change guidance without URL changes. Use that branch rather than applying domain-move procedures indiscriminately.
A hosting move can still break URLs if rewrite rules, trailing-slash behavior, or application configuration differ. Test actual requests. The intended absence of URL changes must be verified rather than assumed.
Handle database URL updates carefully
If temporary or permanent addresses change, use an application-aware method that respects serialized data and the selected scope. Review a dry-run or equivalent preview when the tool provides it, and preserve a current backup.
Do not replace every matching string across every table without understanding its meaning. Some values are identifiers, external destinations, historical records, or environment-specific configuration rather than links that should change.
The WP-CLI search-replace documentation describes available controls for qualified operators. The tool still requires a correct target, reviewed scope, and verification; its existence does not make a broad production replacement automatically safe.
Define the final data boundary for active sites
A destination copied yesterday is already outdated if the source accepted orders, bookings, leads, account changes, or content edits today. Decide how those changes will reach the authoritative destination.
Options may include a coordinated pause followed by a final copy, a supported delta migration, or a specialized application-aware synchronization process. Verify what the selected tool actually handles, including updates to existing records and duplicate prevention.
List all writers: public visitors, staff, APIs, webhooks, scheduled jobs, imports, and external services. A maintenance page may block only one browser route while other writers continue operating.
Record the final source preservation time and the moment at which the destination becomes authoritative. Do not let both installations process the same transactional workload without a deliberate architecture for doing so.
Reconcile external transactions
Compare local records with payment, fulfillment, inventory, and subscription systems where relevant. A successful external payment can exist even if the customer saw an error during the transition.
WooCommerce’s subscription migration and staging guidance explains why clone detection and old-site processing deserve explicit attention. Do not assume that a copied site with the same public URL automatically enters a protected test mode.
Historical orders and current processing are different concerns. Moving old records should not cause new receipts, stock changes, or fulfillment requests. Control those side effects and verify the application-specific result.
Prepare DNS changes as a recorded operation
Capture the current authoritative records and the intended changes. Confirm which records serve the website and which support mail, verification, or other applications.
If useful, reduce the relevant TTL in advance through the responsible DNS provider. That change cannot erase copies already cached under the previous value, and it does not guarantee an instant universal switch.
Check both IPv4 and IPv6 records where used. An updated A record with an obsolete AAAA record can send different visitors to different environments. Review aliases and CDN routing as part of the same request path.
Keep the old environment available appropriately while routing settles, but prevent duplicate transactional processing. Availability of the old server and permission for it to continue writing are separate decisions.
Preserve business email
Changing web records does not inherently move mailboxes. Keep the intended MX records and the relevant authentication, verification, and service records. If authoritative DNS changes, recreate the required zone before delegation changes.
Test sending and receiving through the actual business mail service. Separately test messages generated by WordPress through its intended provider. A working employee inbox does not prove the website’s notification route works.
Ask the mail-service owner to confirm account and billing continuity before canceling any bundled service. A hosting account may also contain mailboxes or forwarding rules that the website migration tool never copies.
Use a launch checklist with explicit acceptance
Before routing traffic, confirm the selected release, current data, certificates, outbound production settings, backup availability, and the people responsible for verification.
Remove staging-only access and indexing restrictions from the intended public application when appropriate. Preserve protection on any remaining test copy. Google’s noindex documentation explains why this setting needs deliberate handling.
Apply the approved DNS or proxy change once, record the time, and watch the relevant application and infrastructure signals. Avoid several people making competing record changes because their local browser shows a different cached result.
Use the business’s normal authorization process for any controlled live transaction. Prefer supported sandbox facilities for rehearsal, and coordinate accounting and fulfillment effects when a live test is necessary.
Verify the public application
Test representative pages through normal visitor sessions and the final hostname. Check important links, downloads, images, mobile navigation, and contact details.
Verify administration, content editing, uploads, and role boundaries. A site can render cached pages while database writes or uploads fail because of ownership or configuration differences.
Check the critical form or transaction end to end. Confirm the receiving system, local record, and external state relevant to the test. A browser success message is only one checkpoint.
Verify the operational application
Review scheduled posts, backups, imports, mail queues, and relevant integration jobs. Confirm that the destination’s scheduler actually runs and that the old environment is not still processing the same work.
The WordPress Cron handbook explains the built-in scheduling model. Hosting system jobs and plugin queues may require additional review.
Do not manually execute every pending job as a health test. Some actions can send messages or process payments. Use the supported component-specific method and record delayed checks that require later observation.
Monitor search behavior after a URL-changing move
Check the final response and content for important old and new URLs. Review redirects, canonical links, sitemap content, indexability, and accidental test-domain references.
If Search Console access is available, use the verified properties and applicable tools for the actual type of move. Do not claim that submitting a sitemap or change request guarantees indexing or preserves rankings.
Watch errors and search patterns over a meaningful period. A temporary fluctuation is not automatically evidence that the migration failed, while a persistent wrong redirect or noindex directive needs correction.
Keep old-URL redirects and domain control according to the applicable search guidance and business needs. Their continued operation depends on a real redirect-serving system, not merely on retaining an unused hosting invoice.
Keep rollback specific and data-aware
A rollback can involve routing, code, configuration, or database state. Decide which type is appropriate to the observed failure rather than treating every problem as a full reversal.
If the destination accepted new records, sending traffic back to an older source can create another divergence. Preserve current destination data and plan reconciliation before reopening source writes.
Record the actual error and proposed correction. A missing form credential may be faster and safer to correct on the destination than to reverse the whole migration. A fundamentally wrong database may require a stronger stop.
Keep communication factual: what is affected, what remains available, who owns the next action, and when the next update will be provided. Avoid an unsupported promise of instant recovery.
Test the paths that a homepage preview misses
A migration rehearsal should include examples of the different request types the application serves. Choose representative pages and actions rather than trying to prove every possible condition with one successful request.
Public content and file delivery
Open a standard page, a blog post, a category or archive, and a search result if the site uses them. Confirm that the intended content appears and that pagination and navigation reach real destinations.
Check a recent upload and an older file. A theme can look correct while the transfer omitted a historical uploads directory. If downloads use access controls, verify that an authorized user can retrieve the file and an unauthorized user cannot.
Inspect generated image sizes and external storage references where relevant. A working thumbnail does not prove the original file moved, and an image that still loads from the old host can conceal an incomplete transfer. Record the actual asset destination before canceling the source service.
Application writes and permissions
Use a safe controlled write, such as saving a draft or uploading a harmless test image through the supported interface. Read-only success does not prove that the application can create files or update the database.
Check ownership and permissions through the destination host’s documented model. Broadly making files writable is not a substitute for correcting ownership. Keep private configuration and backup material protected while giving the application the access it actually needs.
If the site has custom roles, test them separately from the administrator. A migration can preserve content while changing a permission dependency or host rule. The business needs the intended access boundaries, not simply one account that can log in.
Integrations and callbacks
For each important integration, identify both the outbound destination and the inbound callback. A request sent successfully from WordPress does not prove that the return event reaches the correct application.
Check domain allowlists, callback signatures, environment keys, and provider settings through the current official process. A copied configuration can point to an old server-specific URL even when the public domain is unchanged.
Do not manufacture a successful external event by disabling its verification permanently. If the destination cannot validate a callback, preserve the error and correct the supported configuration. Integration acceptance includes both the result and the intended security check.
Time, locale, and scheduled behavior
Review the site’s business time zone and the relevant scheduler configuration. Server time, WordPress settings, and external calendars can differ. Confirm that scheduled work uses the intended business interpretation after the move.
For booking or subscription systems, select a controlled scenario that can be observed safely. A time displayed on a page can be correct while a reminder or renewal action uses a different boundary. Record which delayed behavior was actually checked and which requires follow-up.
Compare the source and destination before launch
A useful comparison has four columns: the function, the source baseline, the destination observation, and the decision. Record differences that matter rather than expecting every infrastructure detail to match.
The destination can legitimately use different cache technology or server paths. What matters is that the application remains compatible, customer data stays correct, and the intended security and performance behavior is acceptable.
For example, a host-managed cache may replace a plugin cache. The comparison should show who configures exclusions for personalized pages and how invalidation works after content changes. Simply copying the old cache plugin can create overlap rather than reproduce the intended behavior.
Similarly, a new mail route may be appropriate when the old host’s mail function is unavailable. Verify sender identity and controlled delivery through the approved provider. Do not treat a different implementation as a failure if it satisfies the agreed outcome safely.
Record known preexisting issues
Identify failures already present on the source before migration. A broken old contact form or missing image should not be mistaken for a new transfer defect, but it should not be silently carried forward without a decision either.
Label each finding as preexisting, introduced during rehearsal, or not yet classified. Assign remediation separately when it falls outside the agreed move. This makes launch decisions more honest and helps the business avoid an argument over what the migration was supposed to fix.
Use monitoring to validate the cutover boundary
After routing changes, compare requests and important events across the old and new environments. Look for evidence that customers, staff, and integrations are using the intended application.
A DNS lookup from one computer is useful but not universal proof. Different resolvers can retain earlier answers, and some integrations use direct endpoints rather than public DNS in the same way a browser does. Review the specific routes that matter to the business.
If new orders appear on both systems, stop treating the move as complete and coordinate reconciliation. Preserve both states before choosing the authoritative record. Avoid copying one database over the other in an attempt to make the lists look identical.
Keep the acceptance decision separate from the copy job
The migration tool can report that its transfer finished before the business has accepted the application. Record both milestones. The technical operator confirms the copy and configuration; the business owner confirms the agreed workflows and remaining limitations.
Use a short sign-off statement naming the version or release, final data boundary, completed tests, and unresolved items. It should not claim that every possible interaction has been tested. A precise acceptance record gives the owner a concrete basis for deciding whether to launch, continue observing, or stop.
Retire the old environment using evidence
There is no universal number of hours after which every old hosting account is safe to cancel. Review routing, traffic, background work, mail dependencies, retained data, and rollback needs.
Confirm that important requests reach the intended destination and that any remaining old-server traffic is understood. Investigate payment callbacks, staff bookmarks, direct integration URLs, and system jobs that do not simply follow the public homepage.
Preserve final archives and logs needed for reconciliation or investigation. Keep them protected with an owner and retention decision rather than leaving an old public application online indefinitely.
Cancel services only after checking their other responsibilities. The old account may host mailboxes, DNS, another domain, backup storage, or downloadable assets. A successful WordPress migration does not establish that none of those remain necessary.
Remove temporary access and artifacts
Remove migration archives and installers from public paths. Revoke temporary accounts or tokens that no longer need access. Keep the business’s intended operational accounts available.
Check that the remaining staging site is protected and cannot send production messages or perform duplicate processing. A useful test environment and an abandoned clone are different things.
Document the final hosting, DNS, mail, backup, and support owners. The next maintainer should be able to identify the authoritative system without reconstructing the migration from old emails.
A compact migration acceptance record
Use a record that links each result to the environment and time tested. Suggested fields include:
- Source and destination identity, with the selected migration branch.
- Backup identifiers and the final current-data preservation point.
- Versions, required extensions, custom code, and host components.
- URL map and representative redirect results where addresses changed.
- DNS records changed and the responsible operator.
- Final certificate and hostname checks.
- Form, booking, checkout, and role-based acceptance results.
- Mail, API, webhook, and scheduled-work results.
- Search settings and public indexability checks.
- Remaining limitations, follow-up owners, and retirement decision.
Keep credentials and customer payloads out of the record. A safe identifier or sanitized screenshot can support a result without creating a new archive of private information.
Separate observed results from assumptions. If a nightly job has not yet run, label it pending and assign someone to review it. Do not turn an untested item green merely because the relevant plugin is active.
Three illustrative migration plans
The following situations are fictional examples of decisions, not client cases or performed tests.
A service website changes hosts but keeps every URL
The team inventories hosting, DNS, forms, and email, then rehearses the site on the destination. Public addresses remain identical, so the project focuses on compatibility, routing, certificates, and business-function verification.
A controlled inquiry confirms delivery through the final production mail route. The team checks existing redirects rather than creating a domain-move redirect system that the project does not need. The old account is retired after its remaining dependencies are reviewed.
A business changes its domain during migration
The owner approves a URL map before launch. The team preserves relevant content, implements permanent redirects to equivalent destinations, and updates internal links, canonicals, and sitemap entries.
After launch, it tests representative old requests and new pages and monitors the applicable verified search properties. It keeps domain and redirect control according to the move plan. No ranking guarantee is attached to the technical work.
A store remains active during preparation
An initial clone supports rehearsal while the source remains authoritative. Before launch, the team coordinates the final data capture and the relevant writers, then reconciles external payment and fulfillment activity.
The destination becomes authoritative at a recorded boundary. The old application is prevented from duplicating jobs or transactions. Acceptance includes current orders and the next supported customer action, not only a familiar storefront layout.
Keep the migration scope separate from unrelated incidents
If the source is already compromised or unreliable, classify that condition before cloning it. A migration can reproduce malicious files, unauthorized accounts, or broken business rules on a new server. Moving infrastructure is not automatically a security cleanup.
Preserve evidence and have the responsible specialist decide which source material is appropriate to transfer. If cleanup or reconstruction becomes part of the project, record its acceptance criteria separately from the hosting move. A familiar homepage on the destination does not establish that the application is clean.
Likewise, an existing unsupported custom plugin may require remediation before the destination can run it safely. Identify that dependency early rather than treating the launch window as the moment to discover its requirements. The business can then choose a supported update, replacement, or revised scope with a concrete explanation of the effect.
Keep the final record honest about what the project achieved. It can confirm a verified move and specific repairs without promising that every historical issue or future failure has been eliminated.
Common migration mistakes to avoid
Combining a hosting move with an unplanned redesign and several major upgrades makes failures harder to attribute. Keep the scope deliberate and test the resulting combination.
Treating a content export as a complete site copy can omit code, media, settings, and plugin records. Confirm the selected tool’s actual coverage and inspect representative results.
Changing nameservers without recreating required mail and verification records can disrupt services that were outside the website project. Preserve the whole required zone when authoritative DNS changes.
Pushing an old staging database over a current store can discard new records. Plan the final synchronization and data boundary before touching production.
Finally, canceling old hosting immediately after a successful homepage test can remove email, callbacks, archives, or rollback options still needed. Retirement should follow evidence about dependencies and application state.
Frequently asked questions
Do I need redirects if only hosting changes?
If the public domain, protocol, and paths stay identical, the hosting move does not itself create a new address to redirect to. Preserve and verify existing response behavior. If addresses change as part of the project, use a separate URL map and the applicable redirect plan.
Does moving WordPress transfer business email?
Not automatically. Mailboxes, forwarding, DNS, authentication, and billing may belong to separate services or the old hosting account. Inventory them and test employee mail separately from WordPress-generated notifications.
Can I migrate without downtime?
Some architectures and tools can reduce disruption substantially, but a universal zero-downtime promise is not justified. Dynamic data, final synchronization, external callbacks, and routing behavior influence the plan. Define acceptable interruption and recovery expectations for the actual site.
Should I update everything before migration?
Supported software matters, but avoid combining unrelated major changes without testing. Record the baseline, review requirements, and choose a compatible destination. Necessary remediation can be part of the project when it has an explicit scope and acceptance plan.
Is a migration plugin enough for an active store?
A plugin can handle important parts of the copy, but confirm its support for current records, updates, custom tables, external assets, and delta behavior. Orders, payments, fulfillment, and subscriptions still require a clear authoritative system and reconciliation.
How should I test before changing DNS?
Use the host’s supported preview or controlled local-resolution method while preserving the intended hostname and secure request context where appropriate. Protect the destination and block unintended outbound actions. An IP-only page test does not verify the full final experience.
When can I cancel the old host?
After confirming the destination is authoritative, relevant traffic and jobs are understood, current data is reconciled, other services are preserved, and rollback and archive needs are addressed. A fixed countdown is not a substitute for those checks.
Will migration preserve my rankings?
Careful URL, content, redirect, and indexing work helps search engines understand the move, but rankings and traffic are not guaranteed. Verify technical behavior and monitor the relevant data rather than treating a successful file copy as an SEO outcome.
Move the application, then verify the business
A dependable migration plan connects infrastructure, URLs, data, and customer workflows. Use the checklist to make responsibilities visible and make each launch decision reviewable.
Web Expert Solutions provides WordPress migration, hosting, DNS, email, and troubleshooting support. If your move involves current transactions, a domain change, or uncertain service ownership, share the source and destination details so the plan can protect recent records and verify the complete customer path.
